Website Size Checker Free Tool

Enter a URL

About Website Size Checker

What This Tool Actually Does

This tool performs one server-side fetch of the URL you enter and returns one number. That number is the byte length of the HTML document itself, measured exactly as the server sent it to this site's machine, without any decompression, without any decoding, and without any follow-up requests. The result appears in a small three-row table that shows the normalised page URL, the exact byte count, and the same count rounded to a whole number of kilobytes.

The measurement happens on this site's server, which runs in Hetzner's Helsinki data centre in Finland. When you submit a URL, the server issues a single PHP file_get_contents() request to that address. No User-Agent header is attached to the request, and no Accept-Encoding header is sent either. Because there is no Accept-Encoding header, the remote server normally sends the HTML in its raw, uncompressed form. The tool then counts the bytes of that final response body. That is the whole process.

Nothing else is fetched. Images are not fetched. CSS files are not fetched. JavaScript files are not fetched. Fonts, video, iframes, and tracking pixels are not fetched. The number you see is the size of one document, the HTML source of the page, and nothing more.

The tool's own live test run for this rewrite produced three reference results. The first was example.com, which resolved to Http://example.com, returned 559 bytes, and displayed as ~1 KB. The second was https://en.wikipedia.org/wiki/Main_Page, which came back as 0 bytes and ~0 KB. The tool returns a zero for that input. The tool lowercases the entire URL, including the path, so Wikipedia's case-sensitive /wiki/Main_Page became /wiki/main_page, which no longer matches a real page. Wikipedia also rejects requests that carry no user agent. The fetch therefore came back empty, and the tool reported 0 bytes. A zero from this tool means the fetch failed or returned nothing. The third test was the string this is not a url, which produced the alert Input Site is not valid! with a Try Again button.

The input is trimmed, lowercased in full, stripped of any leading http:// or https://, and then forced to http://. The tool validates the result as a URL before fetching. Redirects are followed, which matters because most http:// addresses today land on https:// versions of themselves. The socket timeout is 60 seconds, so a slow or unresponsive server will eventually give up and end the request.

The output table shows the Page URL with its first letter capitalised, so example.com appears as Http://example.com. This is a display quirk of the tool's code. The byte count is exact, and the kilobyte figure is the byte count divided by 1024 and rounded to a whole number. The KB value is always prefixed with a tilde, as in ~1 KB, to signal that it is a rounded figure.

What you will not find on this page is any mention of load time, speed scores, resource counts, or comparisons against other pages. The tool does none of those things. It answers one narrow question. How many bytes are in the HTML source of this URL, as delivered to a server in Finland over a plain HTTP request with no browser identification?

That single number has more uses than you might expect, and it also has sharp limits that you should understand before you act on it. This measurement fits into the larger world of web performance by clarifying both sides of the question and correcting the record left by the previous version of this page.

What the Number Really Means

The byte count this tool returns is best described as the raw HTML document size. It is the size of the response body that this site's server received, measured in bytes, before any content encoding was applied by the remote server and before any browser would have parsed, rendered, or executed anything.

The tool measures only the HTML document size. When your browser visits a page, it does not download one thing. It downloads the HTML document first, then parses that document, and then issues a cascade of additional requests for everything the HTML references. Stylesheets, scripts, images, fonts, and other resources each arrive as separate responses. The sum of all those responses is what performance people call total page weight. This tool measures only the first response in that cascade.

The HTML document usually accounts for a small fraction of the total. A page whose HTML is 60 KB might load 3 MB of images, 400 KB of JavaScript, and 200 KB of CSS. The browser's network tab would show a total transfer of roughly 3.7 MB, but this tool reports about sixty kilobytes. Both numbers are correct. They answer different questions.

There is also a difference between the size of a response body and the size of what a browser actually downloads. Modern servers compress HTML with gzip or brotli before sending it. A 100 KB HTML document might compress to 18 KB on the wire. This tool requests without an Accept-Encoding header, so the server usually sends the full, uncompressed document. The number you see is therefore closer to the true source size than to the transfer size, which is a useful property if you want to know how much markup a page contains.

The table above summarises the boundaries. The tool sits firmly in the first row and never crosses into the others. That is by design, and it is also the source of most confusion about what the tool does, because many people arrive here expecting a total page weight checker.

How to Use This Tool

1. Open the tool page. Find the input box above this article, labelled Enter a URL.
2. Enter a full address or a bare domain. You can type example.com or https://example.com/some/path. The tool will strip the scheme, lowercase everything, and force http:// before fetching.
3. Submit the form. Press the Submit button. The tool sends one request from its server in Helsinki and waits for the response body.
4. Read the three-row result table. Look at the Page URL to confirm the normalised address, then read Page Size(Bytes) for the exact count and Page Size(KB) for the rounded figure.
5. Interpret the number in context. A result in the tens of kilobytes means a lean HTML document. A result in the hundreds of kilobytes means heavy markup, inline data, or server-side rendering output. A zero means the fetch failed, not that the page is empty.
6. Run another URL when needed. Use the Try New URL button to check a different page. There is no history, no comparison mode, and no saved results, so each check stands alone.

The workflow is deliberately short. You submit, you wait a moment, you read one number. For a tool whose entire purpose is to report a single figure, that is the right shape.

Correcting the Old Description of This Tool

The previous version of this page described the tool in ways that do not match what the code actually does. Those descriptions need correction, because they led readers to draw conclusions the tool cannot support.

The old copy claimed that the tool measures total page weight, meaning the combined size of the page including images, scripts, CSS, and fonts. The tool measures the HTML document only. A page with 3 MB of images and a sixty-kilobyte HTML file reports approximately sixty kilobytes. If you need total page weight, you need a different tool that fetches the page in a browser context and sums all network responses.

The old copy also claimed that the tool reports compressed or transfer size. It reports raw, uncompressed bytes. The request carries no Accept-Encoding header, so the server normally sends the document without gzip or brotli encoding. The number you see is the source size.

The old copy said the tool counts resources or requests. It counts nothing of the sort. One fetch happens, one response body is measured, and no subresources are requested at all.

The old copy further claimed that the tool shows load time, a speed score, or Core Web Vitals. None of those appear anywhere in the output. The tool does not measure time in any form. It does not compute a score. It does not evaluate Largest Contentful Paint, Interaction to Next Paint, or Cumulative Layout Shift. For those measurements, the related tools listed later in this article are the appropriate choice.

Finally, the old copy stated that the tool keeps a history or compares pages over time. It does neither. Each submission is independent. There is no database of past results, no chart, and no side-by-side comparison.

Those corrections matter because the difference between HTML size and total page weight is not a minor detail. It is the difference between two separate questions about a website, and acting on the wrong answer can send you chasing problems that do not exist.

Why HTML Size Matters for SEO

The relationship between HTML document size and search engine optimisation is real but indirect. Google has never published a hard limit on HTML size as a ranking factor. The company's documentation and public statements focus on render-blocking resources, Core Web Vitals, and mobile usability, not on a byte count of the source document. Yet HTML size still matters for several practical reasons that connect to how crawling and rendering actually work.

Googlebot fetches a page's HTML first, just like any other client. The HTML must be downloaded before it can be parsed, and it must be parsed before any links, structured data, or content can be extracted. A bloated HTML document slows that pipeline. It also consumes more of your crawl budget, the finite number of requests Google makes to your site within a given period. A site with thousands of pages, each carrying 300 KB of HTML, forces Google to spend more bandwidth and time per page than a site whose pages weigh 40 KB each.

The HTML document also carries your inline content. If your page structure, inline styles, and inline scripts occupy 250 KB of the document, that is 250 KB of markup a search engine must process before it reaches the text of your article. Search engines are good at this, and they will find your content regardless. Efficiency is the question.

There is a useful rule of thumb from the networking world that connects HTML size to perceived speed. TCP's initial congestion window, which has been ten packets by default for many years and is often larger in modern stacks, limits how much data a server can send before waiting for acknowledgement. A common estimate puts the first flight at around 14 KB. Content that fits within that first flight can arrive in a single round trip. Content beyond it needs additional round trips. For a visitor on a high-latency connection, the difference between a 12 KB HTML document and a sixty-kilobyte one can mean the difference between one network round trip and several, before the browser even begins to fetch CSS and images.

The Web Almanac, published by the HTTP Archive, gives useful context here. Its 2024 edition reported a median total page weight around 2.6 MB on desktop and 2.3 MB on mobile. HTML itself typically falls in the 30 to 100 KB range for the median page. That means the HTML document is usually a small slice of the total, often under five percent of it. If your HTML is 300 KB while your total page weight is 2 MB, the HTML is disproportionately heavy and worth investigating.

HTML Size Versus Total Page Weight

The distinction between HTML document size and total page weight is the single most important concept to understand about this tool. Total page weight is the sum of every byte transferred to render a page. It includes the HTML, all CSS, all JavaScript, all images, all fonts, all video, and every other subresource. Tools that measure total page weight typically run a headless browser, load the page, and record every network response.

This tool does none of that. It fetches one URL and measures one response body. The result is the HTML document size, which is a component of total page weight but never equal to it, except in the rare case of a page with no subresources at all.

A page with 3 MB of images and a small HTML file of a few dozen kilobytes reports approximately that small size. A typical news article might have an HTML document of 80 KB. It might load 1.5 MB of images, 300 KB of JavaScript, 100 KB of CSS, and 50 KB of fonts. The total page weight is roughly 2 MB. This tool reports approximately 80 KB. If you are debugging a slow page and you check it here, you will see a small number and conclude the page is light. The page is not light. The page is heavy, and the weight lives in the images and scripts.

The reverse situation also occurs. A single-page application might deliver a 400 KB HTML document that contains the entire application shell, inline state, and bootstrapping code. The total page weight might be 1.5 MB. Here the HTML is a large share of the total, and reducing it would meaningfully reduce the first byte of content the browser receives.

This tool measures one layer of a multi-layer system. It is the right tool for questions about markup weight, inline content, and server-side rendering output. It is the wrong tool for questions about what a user's browser actually downloads.

What the Number Is Useful For

The HTML document size reported by this tool has several legitimate uses, and they all centre on the health and efficiency of your markup.

Markup bloat is detected through this measurement. Content management systems, page builders, and theme frameworks have a habit of accumulating inline styles, inline scripts, commented-out code, and redundant wrapper elements. A page that should weigh 40 KB can drift to 150 KB over years of updates. Checking your key pages with this tool gives you a quick baseline. If the number surprises you, the HTML source is worth a look.

The second use is evaluating server-side rendering output. If you run a JavaScript framework with server-side rendering, the HTML document often contains the full rendered markup of the page, including repeated components, serialised state, and hydration data. That document can be much larger than a traditional server-rendered page. Measuring it tells you how much of your payload is markup versus how much arrives later as JavaScript.

The third use is checking whether a page is being served as a real HTML document at all. Some sites respond to crawler requests with a lightweight shell, then populate content via JavaScript. A very small HTML size, under 10 KB, can be a sign that the page relies heavily on client-side rendering. Knowing this matters if you care about how search engines and social media crawlers see your content.

The fourth use is comparing pages within your own site. You can check your homepage, a blog post, a product page, and a category page, then compare the numbers. Large discrepancies often point to specific templates or plugins that inject excessive markup into certain page types.

The fifth use is monitoring the effect of changes. If you remove a heavy plugin, switch themes, or clean up your templates, you can check the same URL before and after. The tool does not store history, so you will need to record the numbers yourself, but the measurement itself is consistent enough for before-and-after comparisons.

None of these uses requires the tool to be fast, to run in a browser, or to measure anything beyond the HTML. The narrowness of the tool is what makes it useful for these jobs.

Understanding the Live Test Results

The live test run for this rewrite produced three results that deserve closer examination, because each one teaches something different about how the tool behaves.

The first test was example.com. The tool returned Http://example.com, 559 bytes, ~1 KB. This is a clean result. Example.com is a small, stable page maintained by the Internet Assigned Numbers Authority for documentation purposes. Its HTML is genuinely tiny, under 600 bytes. The tool fetched it, followed the redirect from http:// to https://, received the body, and counted the bytes. The result matches what you would get from a command-line fetch of the same page.

The second test was https://en.wikipedia.org/wiki/Main_Page. The tool returned Http://en.wikipedia.org/wiki/main_page, 0 bytes, ~0 KB. This result is a failure disguised as a measurement. Two things went wrong. First, the tool lowercased the entire URL, turning the case-sensitive Wikipedia path /wiki/Main_Page into /wiki/main_page, which does not exist. Second, Wikipedia rejects requests without a user agent, so even a correctly cased path would likely have been refused. The fetch came back empty, and the tool reported zero bytes.

This second result is the most important one to understand, because it reveals a genuine limitation. A zero from this tool does not mean the page is empty. It means the fetch failed. The failure could come from a blocked request, a bot challenge, a case-sensitive URL path, or a server that refused to respond without browser identification. When you see zero, you should not conclude anything about the actual size of the page. You should conclude that this tool could not retrieve it.

The third test was the string this is not a url. The tool responded with Input Site is not valid! and a Try Again button. This is the validation path working as intended. The input was trimmed, lowercased, stripped of schemes, and then rejected because it did not form a valid URL structure.

The three tests together show the full range of outcomes. A normal fetch returns a byte count. A blocked or broken fetch returns zero. An invalid input returns an error message. There is no fourth outcome, no partial result, and no indication of whether the fetch succeeded beyond the byte count itself.

Limitations

This tool has limitations that must be acknowledged. The limitations are not defects in the code. They are boundaries of the design, and knowing them prevents you from misreading the results.

It does not measure total page weight. It will never tell you how heavy your images are, how much JavaScript your page loads, or what your visitors actually download. If your page has 3 MB of images and sixty kilobytes of HTML, the tool reports approximately sixty kilobytes. That is correct behaviour, but it is also easy to misread as a sign that your page is light.

The tool reports uncompressed bytes. Because the request sends no Accept-Encoding header, the server normally responds without gzip or brotli compression. A browser, by contrast, always advertises compression support and receives a much smaller transfer. The number you see here is the source size, not the wire size. For a 100 KB HTML document that compresses to 18 KB, this tool reports about 100 KB.

The tool lowercases the entire URL, including the path. This is a real problem for case-sensitive URLs. Wikipedia paths, many CMS routes, and some static file servers distinguish between /About and /about. The tool will change the path before fetching, and if the server cares about case, the fetch will fail or return the wrong page. There is no way to prevent this lowercasing from the input side.

The tool returns zero bytes for blocked or bot-challenged sites, with no error message to explain why. A site that uses Cloudflare, PerimeterX, or a custom bot filter may refuse the request because it carries no user agent. The tool will show 0 bytes and ~0 KB, and you will have no way to tell whether the page is genuinely empty or simply refused service. The Wikipedia test returned a zero result.

The tool accepts one URL per submission. There is no batch mode, no list upload, and no way to check multiple pages in a single request. Each check requires a separate form submission.

The tool keeps no history and offers no comparison. You cannot ask it to show how a page's size changed over the past month, and you cannot compare two pages side by side. If you want trends, you must record the numbers yourself.

The tool makes no mobile and desktop distinction. It fetches the same URL the same way every time, regardless of device type. A page that serves different HTML to mobile and desktop visitors will be measured in only one way, depending on what the server returns to a plain request from Finland.

The tool shows no HTTP status code. If a URL returns a 404 error page, the tool reports the size of that error page's HTML. If a URL redirects to an error page, the tool reports whatever the final response contains. You will not see the status, so you cannot tell whether you measured the page you wanted or an error page.

The tool requires that an http:// address works, at least as a redirect target. The tool forces http:// before fetching. An https://-only site will work only if its http:// address redirects to the secure version. A site that refuses plain HTTP connections outright will return zero.

The rate limit is worth knowing before you run many checks in a row. This tool has no CAPTCHA and no tool-specific request cap. The site as a whole, however, applies a shared throttle to every page. If one visitor address makes more than roughly fifteen requests within a single second, that address receives a 503 error for the rest of the day. For normal use, checking a few URLs with pauses between them, this limit will never matter. For automated scraping of the tool, it will stop you quickly.

Reference Points From the Web Almanac

To interpret the number this tool gives you, it helps to know what typical pages look like. The HTTP Archive publishes an annual Web Almanac that aggregates data from millions of pages. The 2024 edition reported a median total page weight of about 2.6 MB on desktop and 2.3 MB on mobile. These figures include HTML, CSS, JavaScript, images, fonts, and everything else.

HTML itself is a small part of that total for most pages. The Web Almanac's figures place typical HTML documents in the 30 to 100 KB range for the median page. That means the number you get from this tool, for a typical content page, will likely fall somewhere between thirty kilobytes and one hundred kilobytes. A result below 20 KB suggests a lean document, possibly one that relies heavily on client-side rendering. A result above 200 KB suggests heavy markup, inline data, or server-side rendering output that has not been optimised.

The Web Almanac measures real browser loads, which include compression. Its transfer size figures are gzip or brotli compressed. This tool measures uncompressed bytes, so your results will run higher than the compressed figures you might see in the Almanac or in browser developer tools. The relationship between the two depends on how compressible your HTML is, but a factor of three to five is common for typical markup.

Google's Core Web Vitals do not use page size directly. The metrics that matter for ranking, Largest Contentful Paint and Interaction to Next Paint, measure user-perceived experience, not byte counts. A page with a 200 KB HTML document can score perfectly on LCP if its server is fast and its critical resources are optimised. A page with a 20 KB HTML document can fail LCP if its server is slow or its render-blocking resources are heavy. HTML size is one input among many, not a direct ranking signal.

How This Tool Relates to Other Measurements

The web performance world has many tools, and they answer different questions. This tool answers one question only. How big is the HTML document? Other tools answer questions about speed, about total weight, and about the balance of code to content on a page.

A speed checker measures how long a page takes to load, typically from a real browser location. It accounts for server response time, resource loading, and rendering. This tool measures none of those things. A page can have a tiny HTML document and a terrible load time because of slow images or heavy JavaScript. A page can have a large HTML document and a fast load time if the server is quick and the resources are cached.

A pagespeed checker evaluates a page against performance metrics and best practices. It typically produces a score, often based on Lighthouse, and lists opportunities for improvement. This tool produces no score and no recommendations. It reports a byte count and stops.

A code to text ratio checker compares the amount of markup and scripting on a page against the amount of visible text. This is a different axis entirely. A page can have a small HTML document with a poor code to text ratio because most of the document is markup. A page can have a large HTML document with an excellent ratio because most of it is content.

The relationship between these tools is complementary. You might use this tool to check whether your HTML is bloated, the code to text ratio checker to see whether your markup is efficient relative to your content, and the speed or pagespeed checkers to understand the user-facing result of those underlying characteristics.

The Fetch Process in Technical Detail

Understanding exactly what happens when you submit a URL helps you interpret the result correctly. The process has several stages, and each one can affect the number you see.

The tool first takes your input and normalises it. It trims whitespace, lowercases the entire string, strips any leading http:// or https://, and then forces http:// onto the front. This normalisation is why Example.COM/About becomes Http://example.com/about. The lowercasing applies to the path as well as the domain, which is the source of the Wikipedia failure described earlier.

The tool then validates the normalised string as a URL. If validation fails, you see the alert Input Site is not valid! with a Try Again button. This is the only error state the tool reports explicitly. Every other failure mode results in a zero byte count.

The tool issues a single PHP file_get_contents() request from its server in Helsinki. The request carries no User-Agent header and no Accept-Encoding header. The absence of a user agent is significant. Many sites, particularly large ones like Wikipedia, refuse requests that do not identify a browser. The absence of Accept-Encoding means the server will normally send the document uncompressed, since it has no reason to believe the client supports compression.

Redirects are followed. When the tool requests http://example.com, the server responds with a 301 or 302 redirect to https://example.com, and the tool follows it. The byte count comes from the final response body, not from the redirect response. The socket timeout is sixty seconds, so a server that does not respond within that window causes the fetch to fail and the tool to report zero bytes.

The byte count is the length of the response body in bytes. This is a raw count of the characters as transmitted, with each character counting as one byte in the standard ASCII range and multi-byte characters counting as their full UTF-8 length. The tool does not parse the HTML, does not strip comments, and does not normalise whitespace. It counts exactly what the server sent.

The KB figure is the byte count divided by 1024, rounded to a whole number. The tilde prefix signals rounding. A page of just over half a kilobyte shows as ~1 KB because that size divided by the binary kilobyte factor is approximately 0.55, which rounds to 1. A page of about one and a half kilobytes shows as ~1 KB as well, because that size divided by the binary kilobyte factor is approximately 1.46, which also rounds to 1. The byte count is the precise figure. The KB value is for quick reading.

When to Trust the Number and When Not To

The number this tool returns is trustworthy under specific conditions, and you should check those conditions before acting on it.

Trust the number when the URL is a simple, lowercase address that resolves to a public page. A result of just over half a kilobyte for example.com is accurate. A result of a few dozen kilobytes for a blog post on a typical CMS is accurate. The fetch succeeded, the server sent the document uncompressed, and the tool counted the bytes correctly.

Trust the number when you are comparing pages on the same site. If your homepage returns eighty kilobytes and your contact page returns one hundred twenty kilobytes, the difference is real and likely reflects template differences. The measurement method is identical for both, so the comparison is valid even if the absolute numbers differ from what a browser would download.

Do not trust the number when the URL contains capital letters in the path. The tool will lowercase them, and if the server cares about case, you are measuring a different page or nothing at all. Do not trust a zero result as evidence that a page is empty. A zero means the fetch failed, and the failure could come from bot protection, a missing user agent, a case mismatch, or a server timeout.

Do not trust the number as a measure of what your visitors experience. Visitors use browsers that send user agents, accept compression, and download every subresource on the page. Their experience involves total page weight, transfer size, and rendering time. This tool measures none of those.

The practical rule is straightforward. Use this tool for questions about the HTML source itself. Use other tools for questions about page performance, total weight, or user experience.

Related Tools

When you need to know how fast a page loads for a real visitor, use the Website Speed Checker, which measures load time rather than document size.

When you want a performance score with actionable recommendations based on established metrics, use the Pagespeed Checker, which evaluates a page against criteria similar to Google's Lighthouse.

When you want to understand the balance between markup and visible content on a page, use the Code to Text Ratio Checker, which compares the weight of code against the weight of readable text.

Frequently Asked Questions

What exactly does this tool measure?

The tool measures the byte length of the HTML document returned by a single server-side fetch of the URL you enter. It does not measure images, CSS, JavaScript, fonts, or any other subresource. The result is the uncompressed source size of one page.

Why does the tool show a different size than my browser's developer tools?

Your browser sends an Accept-Encoding header, so the server compresses the HTML with gzip or brotli before sending it. This tool sends no such header, so the server responds with uncompressed bytes. The tool also fetches only the HTML, while your browser's network tab sums every resource on the page.

What does a result of 0 bytes mean?

The tool lowercases the entire URL, which can break case-sensitive paths. It also sends no user agent, which causes some sites to refuse the request. A bot challenge, a server timeout, or an https://-only site without a redirect can also produce zero.

Why did the Wikipedia page return 0 bytes in the live test?

The tool lowercased the URL path, turning /wiki/Main_Page into /wiki/main_page, which does not exist on Wikipedia. Wikipedia also rejects requests without a user agent. Either issue alone could cause the failure, and both were present in that test.

Can I use this tool to check my page speed or Core Web Vitals?

No. The tool measures only HTML document size and returns no timing data, no scores, and no performance metrics. For speed and Core Web Vitals, use the Website Speed Checker or Pagespeed Checker linked in the Related Tools section of this article.

How many URLs can I check at once?

One URL per submission. There is no batch mode. The site applies a shared rate limit of roughly fifteen requests per second per visitor address, after which that address is blocked for the rest of the day, but normal use with pauses between checks will never approach that limit.