Page Size Checker: HTML Document Size in KB

Web page size is the HTML document, not the whole download.

Ask three page size checkers about one URL and you can get three very different numbers, because they are measuring different things. Here is which number this tool reports, why it is the one Google's crawler limit is written against, and what to do when a page gets close.

What a page size checker measures

"Page size" has two common meanings, and the tools ranking for the term split between them. The first is the HTML document: the single file the server returns for the URL, holding the markup, the text and anything written into it inline. The second is total page weight: that file plus every image, stylesheet, script, font and video the browser then downloads to draw the page. On an ordinary page the second is many times the first, because images alone usually outweigh the markup.

This tool reports the first, and says so in its name. It is an HTML size checker: one request for the document, one byte count. It does not follow the document's links to images or scripts, so a page with a 4 MB hero photo and a lean 60 KB of HTML reads as 60 KB here. If you want total weight, a browser's network panel or a performance test gives it. If you want to know whether Google's crawler reads all of your HTML, this is the number that answers it.

Some people who search to check website size mean something else again: how much disk space a whole site takes on its hosting plan. That is a question for the host's control panel. A page size checker works one URL at a time.

Uncompressed versus transfer size

Almost every server compresses HTML on the way out, with gzip or Brotli, and the browser expands it on arrival. So a single document has two sizes: what crosses the network and what it expands to. The gap is large, because markup repeats itself and compresses well. Willowdale Equity's home page, fetched on 28 September 2026, crossed the network as 17,541 bytes of Brotli and expanded to 81,311 bytes of HTML. Verand's own home page the same day was 322,780 bytes on the wire and 1,989,882 once expanded.

This tool reports the expanded figure, because that is the figure Google's limit is written against. Google's Googlebot documentation is direct about it: "The file size limit is applied on the uncompressed data." A page can be quick to download and still be too large for the crawler, which is the one situation where turning compression up does nothing. Those transfer figures above were measured separately with a plain HTTP client; the tool itself returns only the uncompressed size.

How much HTML Googlebot reads

Google's documentation for Googlebot says: "When crawling for Google Search, Googlebot crawls the first 2MB of a supported file type, and the first 64MB of a PDF file." Its Search Central blog post of 31 March 2026, "Inside Googlebot: demystifying crawling, fetching, and the bytes we process", spells out what happens at the line. "If your HTML file is larger than 2MB, Googlebot doesn't reject the page. Instead, it stops the fetch exactly at the 2MB cutoff." The part it did fetch "is passed along to our indexing systems and the Web Rendering Service (WRS) as if it were the complete file", and "any bytes that exist after that 2MB threshold are entirely ignored."

Two details matter for reading the number here. The same post says the 2MB is counted "including the HTTP header", which this tool does not measure, so treat a page within a few kilobytes of the line as over it. And the limit applies to each file separately: "external scripts, and stylesheets are fetched separately (subject to their own limits)." That is why moving inline CSS or JavaScript into its own file is the standard fix, and why it works.

You will still find tool pages quoting a 15MB Googlebot limit. Google's post gives 15MB as the default for its other crawlers that do not specify a limit, not for Googlebot fetching HTML for Search. A page checked against 15MB can pass comfortably and still lose its last few hundred kilobytes to Googlebot.

Our own home page went over the line

This is not a hypothetical. When we ran this check on verand.ai on 27 September 2026, the home page served 2,165,042 bytes of HTML: 165,042 bytes past a 2,000,000-byte line, and past the line on the 1,048,576-byte reading too. The page is built as one self-contained file, and more than half of it was CSS written inline. Measured on 28 September, after the page had changed, 1,113,385 bytes sat inside <style> elements, 216,238 in inline SVG and 54,815 in inline scripts, against about 74 KB of the words a visitor actually reads.

By the next day it had come back under, at 1,990,249 bytes, which is 99.5% of the line: close enough that one more section would push it over again. The saved run on this page is the 27 September result, and it fails. The lesson is the one Google's post draws. The words were never the problem. The weight was styling and markup that could have been separate files.

Why the footer is the part at risk

Googlebot keeps the first 2MB and drops the rest, so what matters is not only how large a page is but what sits at the end. On nearly every site the end of the HTML is the footer: the address, the licence numbers, the privacy and accessibility links and, for a financial adviser, an insurance agency, a law firm or a medical practice, the disclosures the firm is required or advised to carry on every page. On verand.ai on 28 September, the footer began at byte 1,913,895 of 1,989,882, inside the last 4% of the file. The footer is the last thing in the file, so on the 27 September version, with 165,042 bytes past the line, it was the part Googlebot would have dropped.

Most pages are nowhere near this, so the honest advice is to check once and move on, and to check again whenever a page gets a heavy page-builder layout, an embedded widget, a large inline map or chart, or a design system pasted into the head. If a page ever does run long, the disclosures are the first thing Google stops reading.

What a normal HTML page size looks like

Google publishes a limit, not a target. The best public picture of typical sizes comes from HTTP Archive data analysed by Dave Smart in "2 MB is a lot of HTML" (February 2026), measuring the main document alone, desktop crawl:

Over the network the same median home page is about 22 KB, so a figure of around 20 KB is a compressed size, not an HTML size. Willowdale Equity's pages sit right at the middle of that table, between about 80 KB and 110 KB of uncompressed HTML each, with the home page at 81,678 bytes and a 3,261-word article at 110,185. The card shows where your page falls against the median and the 90th percentile for its kind.

Ratings like "good under 100 KB, poor over 500 KB", or claims that Google recommends HTML under 15 KB or 100 KB, are conventions of the tools that print them. We found no Google source for any of them. Treat any band, including the context on this card, as a comparison, not a rule.

What makes HTML bloated

• Inline CSS. A whole stylesheet pasted into a <style> element, often by a theme or page builder that inlines "critical CSS" and then everything else too. The largest single cause on the pages we have measured, our own included.
• Inline JavaScript and embedded data. Framework state serialised into the page as JSON so the browser can pick up where the server left off, analytics bundles, and chat widgets that write their code into the document.
• Base64 images. An image encoded as text inside the HTML costs about a third more than the file it replaces, and it cannot be cached separately.
• Inline SVG. Icons and illustrations drawn in markup, repeated every time they appear. One icon is nothing; a mega-menu of them on every page adds up.
• Page-builder markup. Wrapper inside wrapper inside wrapper, each with its own classes and inline styles, around a paragraph of text.
• Navigation twice. Separate desktop and mobile menus, both in the HTML, each carrying the full site structure.

Why this differs from PageSpeed and other tools

PageSpeed Insights and browser performance tests report the bytes of every request the page makes, as transferred, so they fold in images, scripts and fonts and count them compressed. This tool reports one file, expanded. Neither is wrong; they answer different questions, and the two can move in opposite directions. Inlining a stylesheet saves a request, which a speed test may like, and adds its whole size to the HTML, which is what counts against Googlebot's 2MB. Small differences from other HTML checkers come from compression, from counting characters instead of bytes, and from a page serving different HTML to different user agents.

Common mistakes

• Reading total page weight as HTML size. A 5 MB page is usually 4.8 MB of images. The HTML is what the 2MB applies to.
• Checking the compressed size against the limit. Google measures uncompressed. A page that is 300 KB on the wire can be over 2MB of HTML.
• Using the old 15MB figure. It is the default for Google's other crawlers, not Googlebot's HTML limit.
• Putting key content last. Structured data, the article body and disclosures that sit after megabytes of menus and styles are the first things past the cutoff.
• Chasing a small number for its own sake. A 150 KB page is not a problem. Under the line, size is a speed question, not a crawling one.

HTML page size, in one line

Measure the uncompressed HTML, keep it well under 2MB, and if a page runs long, move what is inline into files before the footer, and whatever it has to say, falls past the line.