Page Size Checker

How big is a page's HTML?

This checker answers one narrow question: how many bytes of HTML does a URL return? Our server requests the page, decompresses it if needed, and counts the bytes of the HTML document. Images, stylesheets, scripts and fonts are separate files and aren't included, so the number is the document alone, the first thing a browser or crawler has to download and parse.

That narrowness is the point. Total page weight is dominated by images and JavaScript bundles, and lots of tools already report it. The HTML document's own size tells you something different: how much markup and inline data the server is stuffing into every response.

What a result looks like

HTML document size: 48213 bytes (~47.1 KB). This measures the HTML document itself only, not the images, CSS, or JavaScript it references.

The byte count is exact for whatever the server returned. KB is bytes ÷ 1,024 rounded to one decimal.

Three different "page sizes"

People mean different things by page size, and mixing them up causes most of the confusion around results like this:

Text compresses well, so a 300 KB HTML document might cross the network as a fraction of that. The uncompressed figure still matters: the browser has to parse every byte, and a crawler's size limit applies to the file it processes.

Does HTML size matter for search?

Google documents a hard limit. Its Googlebot page says Googlebot crawls the first 2 MB of a supported file type (64 MB for PDFs), and only the part it downloaded is considered for indexing. Each referenced resource, such as CSS or JavaScript, is fetched separately.

Ordinary pages are nowhere near that. Where it bites is pages carrying huge inline payloads: a product listing that embeds the whole catalogue as JSON, or an article with dozens of base64 images. If a page's important content sits at the end of a very large document, it can fall past the cutoff.

This tool's own read limit is 2,000,000 bytes. If the result says more than 2000000 bytes, the page is at least that big, and content near the end is at risk of being cut off by crawlers too.

Why HTML gets heavy

When a document is far bigger than its visible content would suggest, the usual causes are:

• Inline framework state. Server-rendered React, Vue or Next.js apps often embed the page's data as a JSON blob in a <script> tag so the client can hydrate. That can easily outweigh the visible markup.
• Base64-embedded images. Base64 encodes every 3 bytes as 4 characters (RFC 4648), so an inlined image is about a third larger than the file, and it can't be cached separately. The image to Base64 tool shows how fast that adds up.
• Inline SVG icons repeated in every card of a long list.
• Inline CSS from page builders or critical-CSS plugins that got out of hand.
• Huge navigation menus with hundreds of links rendered on every page.

Trimming a heavy document

1. Measure it here and note the number.
2. Open the page source and search for the largest <script>, <style> and <svg> blocks.
3. Move large data and styles into external files that browsers can cache between pages.
4. Replace base64 images with normal image files, compressed with the image compressor.
5. Minify what remains. The HTML minifier strips comments and extra whitespace.
6. Measure again to confirm the drop.

Then look at the code-to-text ratio for the same URL, which shows how much of the remaining bytes is visible text versus markup and stylesheet code.

How the fetch works

The URL you enter is sent to our server, which makes the request. It follows up to ten redirects and measures the final page, so entering http:// on an https site measures the https page. Each response gets eight seconds. Only http:// and https:// URLs are accepted, hostnames are resolved over IPv4 and IPv6, and any address in a private or reserved range is refused, including after a redirect. The server also doesn't run JavaScript, so content a script would fetch after load isn't counted.