Code to Text Ratio Checker Free Tool
Enter a URL
About Code to Text Ratio Checker
What This Tool Actually Does
Paste a URL into the box above, submit it, and this tool fetches that page's raw HTML, strips out everything that isn't visible reading text, and compares the byte size of what's left against the byte size of the full document. The result is a single percentage: how much of the page, by weight, is words a visitor can actually read versus markup, inline scripts, inline styles, and structural tags that exist purely for the browser to parse. Alongside that percentage, you'll see the two raw numbers it's built from: the size of the extracted text and the size of the total HTML.
That's the whole tool. It's a calculator, not a source-code viewer: it never shows you the HTML itself, only the arithmetic. If you want to actually see the raw markup a page ships, this site runs a separate Website Source Code tool for that; this one exists purely to answer "what's the text-to-code balance," reduced to one number.
One fact worth stating up front, because it changes how you should read any result: the fetch behind this check is a plain HTTP request, not a browser. There's no JavaScript execution involved at any point. Whatever text a page builds client-side, after the initial HTML loads, is invisible to this tool. The mechanics section below explains exactly why that matters and how the rest of the calculation works.
Also worth clearing up before anything else: despite the name, the percentage this tool shows is the share of the page that is text, not the share that's code. A higher number means the page leans more toward reading content and less toward markup; a lower number means the opposite. It's easy to assume "ratio" means a code-to-text comparison expressed the way the name literally reads, but the actual figure on screen is a text-to-total-size percentage. Knowing that upfront avoids reading a high number as a bad sign or a low one as good.
How the Calculation Actually Works, Step by Step
Here's what happens between submitting a URL and seeing a result, described the way the code behind this page actually runs it. Not a simplified summary, the real sequence.
- Your input is validated first. Whatever you type is trimmed, a scheme (
http://) is added automatically if you didn't include one, and the result is checked with a standard URL validator. If it still doesn't validate, the tool stops immediately with an "Input Site is not valid!" error and nothing gets fetched. - No CAPTCHA gates this particular tool. Unlike a couple of other tools on this site, this one has no CAPTCHA challenge in front of it. That's a checkable fact about how this specific tool is configured in the site's own database, not an assumption carried over from a different tool. (There's a site-wide IP throttle behind every tool on the site, but its threshold is loose enough that normal back-to-back checking never hits it.)
- The page is fetched with one plain GET request. The tool sends a spoofed desktop Chrome user-agent string and a Google.com referer, follows redirects (up to 100 of them), and gives the request 30 seconds to connect and 30 seconds total to finish. Whatever HTML comes back from that single request is the entire universe of content the rest of this calculation ever sees. A fresh, empty cookie jar is created for that one request too, so nothing about a prior visit or a logged-in session carries over between checks.
- SSL certificate checking is relaxed on this fetch. The request will still go through and fetch a page even if that page is running behind a broken, expired, or self-signed certificate. It's a minor implementation detail rather than something that changes the ratio math, but worth knowing if you're testing a staging or internal URL with certificate issues and still want a reading.
- This checks one page at a time, not a whole site. There's no crawling behavior anywhere in this tool. Submit one URL, get one result for that exact page. Checking a whole site means running the tool once per URL you care about, the same way you'd run any single-page check repeatedly.
- A dead or unreachable URL produces an honest error, not a fake result. If the fetch comes back empty (the site's down, the connection times out, the URL doesn't resolve), you'll see "Requested URL looks down!" and no percentage is calculated at all.
- The raw HTML's byte length is measured first, before anything is touched. This becomes the "Total HTML size" number in your result: the full page exactly as delivered, decompressed if it arrived gzip-compressed, but otherwise untouched.
- One pass strips everything that isn't reading text. Entire
<script>...</script>blocks are removed, entire<style>...</style>blocks are removed, and every remaining HTML tag (opening, closing, and every attribute inside it) is stripped along with raw line breaks and tab characters. A second pass then collapses any run of multiple spaces down to one space. - What's left is measured again. The byte length of that stripped-down text becomes "Text content size": the actual visible words, with all markup, inline code, and attribute values gone.
- The percentage is a straight division, nothing more. Text size, multiplied by 100, divided by total HTML size. There's no weighting, no separate scoring model, no adjustment for page type. It's the same three-line arithmetic every time, on every URL.
- The displayed percentage is truncated, not always rounded to a fixed number of decimals. Most results show up as something like "42.7%," but an occasional clean whole-number result can display with no decimal point at all. It's a cosmetic quirk of how the number gets formatted for display, not a sign the math itself changed.
That's the entire process: one HTTP request, one strip-and-measure pass, one division. There's no hidden crawl budget, no multi-page analysis, and (this is the part worth repeating) no step anywhere that runs the page's JavaScript. What the tool measures is exactly, and only, what the server sent back on that one request.
How to Use This Tool
- Open the page and find the input box. It accepts a full URL; including
https://is fine, and the tool will add a scheme automatically if you leave it off. - Paste or type the URL of the page you want to check. Use the exact page you care about, not just the domain's homepage, since the ratio is calculated per-page, not site-wide.
- Submit the form. The tool fetches that URL's live HTML in the background. There's no preview step, it's a single request.
- Read the three numbers in the result. A percentage labeled "Code to Text Ratio," plus the byte size of the extracted text and the byte size of the total HTML underneath it.
- If you get "Requested URL looks down," try the URL directly in a browser first. That error means the fetch itself failed (a dead link, a timeout, or a site that's actually unreachable), not that the ratio came back at zero.
- Check another URL any time. There's no per-tool waiting period or CAPTCHA, so comparing several pages back to back, your own pages or a handful of competing pages for the same query, works fine.
Reading Your Result: Ratio, Text Size, HTML Size
Every successful check returns three numbers, and it helps to know exactly what each one is measuring before drawing any conclusion from them.
| Field | What it actually measures |
|---|---|
| Code to Text Ratio | Text byte size divided by total HTML byte size, as a percentage. Higher means more of the page's weight is visible text; lower means more of it is markup, scripts, and styles. |
| Text content size | Byte length of what's left after every script block, style block, tag, and attribute is stripped and repeated spaces are collapsed. The reading content only. |
| Total HTML size | Byte length of the full page as delivered, after gzip decompression, before any stripping. A decompressed count, not the smaller compressed size that traveled over the network. |
Note what isn't in this table. There's no separate "code size" number displayed anywhere on the result. It's implied (total size minus text size) but the tool never shows it as its own figure.
There's also no fourth field showing the raw HTML itself. If you want to actually read the markup this calculation ran against, that's a different tool on this site entirely.
Is Code-to-Text Ratio a Google Ranking Factor? (Debunking a Persistent SEO Myth)
No. Google has never confirmed a code-to-text ratio, or any specific percentage threshold, as a ranking input. There is no official "70% text, 30% code" rule, no documented cutoff below which a page gets penalized, and no published formula tying this metric to search visibility. This has been stated plainly, more than once, by people on Google's own Search Relations team over the years. If you've read that a specific ratio is required to rank well, that claim doesn't hold up against anything Google has actually said.
The myth persists for a genuinely understandable reason, and it's worth walking through exactly why, because the confusion is more subtle than a simple made-up statistic. Pages with an unusually low ratio are sometimes, coincidentally, pages with real, separate problems: bloated inline CSS and JavaScript that slow the page down, excessive third-party widget markup, or (a completely different issue) genuinely thin content padded out with heavy templating.
Slow pages and thin content are things that can plausibly affect how a page performs in search, on their own merits, for reasons that have nothing to do with a byte-ratio. The ratio itself doesn't cause either of those problems. It's a rough, purely mechanical proxy that sometimes happens to correlate with one of them.
Mistaking that loose correlation for a direct causal ranking signal is exactly how the myth spreads: someone notices a low-ratio page also ranks poorly, and skips past every other explanation to land on the ratio itself as the cause.
Here's the practical test that breaks the myth cleanly. A product-filter page, a documentation hub, or an interactive web-app dashboard can carry a legitimately low ratio indefinitely (heavy on navigation, filters, thumbnails, and UI chrome relative to running prose) and rank perfectly well for exactly what it's supposed to rank for, because it's serving its actual purpose well.
Meanwhile, a page with a perfectly "healthy" ratio by any reference band, but genuinely thin, unhelpful content underneath that clean structure, won't rank on the strength of its ratio alone. The number describes the shape of a page's HTML. It does not describe whether the content is any good, and it is not what Google's ranking systems are evaluating when they assess a page.
What a Low or High Ratio Typically Signals
None of the bands below are official thresholds. No search engine has published a target percentage, and the entire idea of a universal "correct" number falls apart the moment you compare two structurally different kinds of pages. Treat this table as a rough, practical reference for interpreting a result, not a checklist to hit.
| Ratio range | What it usually indicates | Typical next step |
|---|---|---|
| Under 10% | Heavy inline markup/scripts, or genuinely thin content relative to the page's total weight | Check whether the cause is bloated code or actually thin text (see the word-count pairing below) |
| 10% to 25% | Common and normal for template-heavy pages: product listings, filters, dashboards, category pages | Usually fine if the page's job is navigation/functionality rather than long-form reading |
| 25% to 60% | Typical range for well-structured articles, blog posts, and other text-driven content pages | Generally no action needed; this is the expected zone for prose-heavy pages |
| Over 60% | A very text-dense page with minimal styling or scripting overhead | Fine for plain long-form content; worth a quick look that the page still renders and looks acceptable with that little styling |
These bands genuinely shift by page type, and that's not a caveat to skim past. It's the main reason a single fixed target never made sense in the first place. A product category page with faceted filters, thumbnail grids, and pagination controls will structurally always carry more markup relative to text than a single long-form article does, and that difference reflects the two pages doing different jobs, not one of them doing its job badly.
The Real Reasons to Run This Check
Away from the ranking-factor myth, there are a handful of genuinely practical, non-mythical reasons people reach for this specific number.
Spotting markup and script bloat as a quick diagnostic flag
An unusually low ratio on a page that's supposed to be mostly reading content (a blog post, an article, a long-form guide) is a fast, free first signal that something upstream might be worth a closer look: inline CSS or JavaScript that should have been moved into external, cacheable files, verbose nested wrapper markup left over from a page builder, or a growing pile of third-party widgets each adding their own bytes without adding a single word a reader sees. It's a starting point for an audit, not the audit itself.
Telling "too much code" apart from "too little content"
A low ratio has two very different possible causes, and this number alone can't tell you which one you're looking at. Pairing this check with a straightforward word count on the same page (see Word & Character Counter) tells you whether the low ratio is coming from markup weight sitting on top of perfectly reasonable content, or from a page that's genuinely thin on words no matter how you slim down the code around it. Those are two different fixes, and running both checks together, instead of just this one, is what actually points you toward the right one.
Comparing before and after a redesign or CMS migration
Running the same URL, or the old and new version of a template, through this checker before and after a page-builder switch, theme change, or CMS migration is a quick way to flag whether the new templates are quietly adding markup weight that wasn't there before. It won't tell you why on its own, but a noticeable ratio drop across several migrated pages is a reasonable prompt to go look at what the new templates are actually outputting.
As a quick pre-publish habit check
Some writers and editors run a freshly drafted article through a check like this one right before publishing, alongside a word count, mostly to catch pages that came out unexpectedly thin once the template and boilerplate are accounted for. It's a small, honest habit: if a page that's supposed to be a full-length guide comes back with a surprisingly low ratio and a low word count together, that's worth a second look before it goes live, rather than after it's already indexed.
Limitations: What This Number Doesn't Tell You
A few honest limits keep this tool useful instead of misleading, and the first one below matters more than the rest combined.
- No JavaScript rendering happens at any point, full stop. This is the single biggest thing to understand before trusting a result. The fetch behind this tool is a plain HTTP request with no rendering engine attached: no headless browser step, no DOM construction, nothing that executes a page's JavaScript.
- JS-heavy pages will read artificially low. If a page builds most of its visible text client-side (a React or Vue single-page app, or any template that lazy-loads its main body content via JavaScript after the initial HTML arrives), this tool only ever sees the sparse initial HTML shell, not the fully rendered page a real visitor sees in their browser. That produces an artificially low ratio that has nothing to do with the page's actual content quality. It reflects a gap between what this checker can see and what a browser (or, separately, Google's own indexing pipeline, which does render JavaScript) actually sees.
- There is no single universally "correct" target ratio. Different page types have fundamentally different structural needs, and treating a documentation page, a product listing, and a long-form article as directly comparable on this one metric is the most common way this number gets misread.
- "Total HTML size" is a decompressed byte count, not a network transfer size. The fetch automatically decompresses gzip-encoded responses before measuring, so this figure reflects the full, uncompressed HTML, typically several times larger than what actually traveled over the wire. If you're cross-referencing this against a page-speed tool's transfer-size figure, know that the two numbers are measuring genuinely different things.
- Login-gated and cookie-dependent pages can't be evaluated meaningfully. Each check uses a fresh, empty session with no saved login state. A page whose real content only appears after signing in, or behind a paywall, won't return a meaningful reading either way, since the fetch never gets past the gate to begin with.
- A result reflects one moment, not a trend. Pages that serve different HTML depending on the situation (A/B tests, personalization, geo-targeted variants) can return a different ratio on a repeat check of the exact same URL. Treat any single result as a snapshot, not a fixed property of the page.
- A "good" ratio doesn't guarantee good content, and a "bad" one doesn't guarantee bad content. It's a structural read on the shape of a page's HTML (how much of it is markup versus reading text), not a judgment on whether the words themselves are useful, accurate, or well-written.
Related Tools
This ratio is most useful as one data point alongside a couple of other quick checks, rather than as a standalone verdict.
- Website Source Code: if you want to actually read the raw HTML this calculation ran against, rather than just the resulting percentage, this is the tool for that. Useful for confirming exactly what's driving an unexpectedly low or high ratio on a specific page.
- Word & Character Counter: pairs directly with this tool to separate "too much code" from "too little content" as the real cause of a low ratio, since this checker alone can't distinguish between the two.
- Website Speed Checker: confirms whether the same markup bloat flagged by a low ratio is also costing real page-load time, not just a lower percentage on this one metric.
Frequently Asked Questions
Does a low code-to-text ratio directly hurt my search rankings?
No. Google has never confirmed a specific code-to-text percentage as a ranking input. A low ratio is more useful as a diagnostic flag that sometimes points toward a separate, real issue (bloated markup or genuinely thin content), but the ratio itself isn't a documented ranking factor. See the dedicated section above for the full explanation.
Why does this tool show a much lower ratio for my JavaScript-heavy site than I expected?
Because this tool never executes JavaScript. It only measures the raw HTML from a single, plain HTTP fetch. If your page builds most of its visible text client-side after the initial load, that text simply isn't present in what this tool measures, which pushes the ratio artificially low regardless of how much real content actually appears once a browser renders the page.
What counts as a "good" ratio for my page?
There's no official target published by any search engine. As a loose, page-type-dependent reference, long-form articles commonly land somewhere in the 25%-60% range, while template-heavy pages like product listings or dashboards naturally run lower without that being a problem. Compare a page against similar page types, not against a fixed number.
Why do different code-to-text ratio tools give different percentages for the same page?
Tools differ in exactly what they strip before measuring and what they count as "text." Some may treat attribute values or comments differently, some normalize whitespace differently, and fetch conditions (user-agent, whether JavaScript is executed) can differ between tools too. Use one tool consistently when comparing pages over time rather than mixing results from different checkers.
Can this tool check a page that requires a login to view?
No. Each check runs with a fresh, empty session and no saved credentials, so a page whose real content is gated behind a login or paywall won't return a meaningful result. The fetch simply won't get past the gate.
Is there a limit on how many URLs I can check?
This specific tool has no CAPTCHA gate, so checking several URLs back to back, your own pages or a handful of competing pages for the same query, works fine. (A loose site-wide IP throttle sits behind every tool on the site, but normal use never gets close to it.)
Does minifying my HTML change this ratio?
Yes, and it's worth knowing before comparing a minified page against an unminified one. Minification strips formatting whitespace, line breaks, and sometimes comments from the "code" side of the count without touching the visible text at all, which raises the ratio purely as a side effect of build tooling rather than any change in actual content. Two pages with identical visible text can show noticeably different ratios purely because one is minified and the other isn't.