Page Size Checker

Measure the size of a page's HTML document. Enter a URL and this tool fetches it and reports the transfer size on the wire (compressed, what actually crosses the network) and the decompressed size the browser parses, along with the compression saving. This is the size of the initial HTML response — the first thing that must download before a page can begin to render.

How to use the Page Size Checker

Enter a URL and press Check page size. The tool fetches the document and reports:

• The decompressed size — how many bytes of HTML the browser actually parses, colour-coded (green under 512 KB, amber to 1.5 MB, red beyond).
• The transfer size on the wire — the compressed bytes that travel the network, when the server reports it.
• The compression in use and the percentage saved.

This measures the HTML document only. The images, CSS, JavaScript and fonts the page references are separate downloads and are not counted here, so the full page weight a browser ends up loading is usually much larger.

Why HTML document size matters

When a browser loads a page, the very first thing it downloads is the HTML document. Everything else — stylesheets, scripts, images, fonts — is discovered by parsing that HTML, so the document has to arrive and start parsing before the rest of the page can even begin. A bloated HTML response therefore delays everything downstream.

There are two numbers worth separating, and this tool shows both:

• Transfer size — the compressed bytes that actually cross the network. This is what consumes bandwidth and time on the wire, and what you are billed for on metered hosting.
• Decompressed size — the full HTML the browser has to parse and hold in memory after expanding it. A page can be small on the wire yet large to parse if it is mostly repetitive markup that compresses well.

HTML documents balloon for recognisable reasons: huge inline CSS or JavaScript dumped into the page instead of cached external files, enormous inline SVGs, base64-encoded images embedded as data URIs, server-rendered frameworks that serialise a large state blob into the markup, or simply very long pages. Keeping the document lean — externalising and caching CSS/JS, avoiding inline data URIs for large images, and paginating or lazy-loading long content — means the browser gets to first paint sooner. Because this measures only the document, pair it with the compression check (is the HTML even gzipped?) and remember the real page weight includes all the sub-resources this number excludes.

Common use cases

• Catching HTML bloat — find pages whose document is unexpectedly large from inline CSS, JS or data URIs.
• Measuring transfer cost — see the compressed bytes that actually cross the network per request.
• Checking compression impact — compare transfer versus decompressed size to confirm compression is helping.
• Comparing pages — benchmark the document size of a heavy template against a lean one.
• Tracking a refactor — confirm a change actually shrank the HTML payload.

Document size vs full page weight

It is important not to confuse these two, because they answer different questions:

• HTML document size (this tool) — just the initial markup response. It governs how quickly the browser can start parsing and discovering other resources. Typically tens to a few hundred kilobytes.
• Full page weight — the document plus every image, stylesheet, script, font and XHR it triggers. This is what page-speed tools and browser dev-tools report as the total, and it is usually several times larger, often measured in megabytes.

A small HTML document with heavy sub-resources can still be a slow page, and a large HTML document can be slow even with light assets. To reduce the document specifically: move large inline <style> and <script> blocks into cached external files, avoid embedding big images as base64 data URIs, and split very long pages. To reduce full page weight, also optimise the images, fonts and scripts the document links to.