What the text-to-HTML ratio measures
This tool fetches a page, strips out everything that is markup, scripts, and styling, and compares the size of the readable text that remains against the size of the full HTML document. The result is a percentage: how much of what your server sends down the wire is actual content a person would read versus how much is the scaffolding browsers need to display it. A page that is mostly text scores high; a page buried under inline scripts and bloated markup scores low.
The number itself is not a Google ranking factor, and you should be skeptical of anyone who claims a magic threshold. What it really is, is a fast, cheap proxy for two things that do matter: whether a page has enough substantive content to be worth ranking, and whether the page is carrying so much code weight that it will be slow and hard to render. Think of it as a health check, not a score to game.
How the ratio is calculated
The checker takes the raw HTML response, the same bytes a crawler downloads before any JavaScript runs, and measures its total size. Then it removes the tags, the contents of script and style blocks, comments, and other non-visible markup, leaving the plain text. It divides the size of that text by the size of the full document and reports the percentage, often alongside the raw character or byte counts so you can see the absolute numbers behind the ratio.
Because it works on the raw HTML rather than the rendered page, the ratio reflects what arrives before client-side rendering. If your content is injected by JavaScript after load, the raw HTML may be almost all code with very little text, which is itself a useful warning: a page that ships an empty shell and builds its content in the browser is harder for crawlers and AI bots to read reliably.
How to read your ratio
There is no universal pass mark, but the shape of the result tells a story. A content page, a blog post, a guide, a product description, that comes back with a very low text ratio usually means one of two problems: the page is genuinely thin on words, or the HTML is bloated with inline scripts, tracking snippets, and heavy framework markup that dwarf the actual writing. Either is worth investigating.
A higher ratio on a content page is generally a good sign, but do not chase the percentage for its own sake. A landing page that is mostly a hero image and a form will always have a low ratio and that is fine, because its job is conversion, not reading. Always interpret the number against what the page is for. The ratio is most useful when it surprises you, when an article you thought was substantial turns out to be mostly markup.
What drags a ratio down
The biggest culprit is inline JavaScript and CSS, large blocks of code pasted directly into the HTML instead of loaded from external files. Tag managers, analytics, chat widgets, and consent banners all love to inject inline script, and on a lightly written page they can easily outweigh the content several times over. Moving that code to external, cacheable files cuts the HTML size and lifts the ratio without touching a word of content.
Bloated, deeply nested markup is the other big factor. Page builders and some component frameworks wrap every element in layers of div tags with long class lists, so a paragraph of text ships inside a paragraph of markup. Excessive whitespace, repeated boilerplate, and giant inlined SVGs or data-URI images pad the HTML further. None of it helps the reader and all of it slows the download and the parse.
Raw HTML versus the rendered page
It is worth being precise about which version of the page this tool measures. It reads the raw HTML your server returns, before a browser executes any JavaScript. That is deliberate, because it matches the first thing a crawler downloads. A page can look content-rich in the browser yet ship a raw document that is almost entirely code, with the words painted in afterward by script. The ratio exposes exactly that gap.
If your text ratio is very low and you know the page has plenty of content, client-side rendering is the likely cause. The content exists, but it is not in the bytes a crawler reads first. That is not just a ratio curiosity; it is a real indexing risk, because not every crawler and not every AI bot will run your JavaScript to reveal the text. Server-rendering or statically generating the important content puts it back into the raw HTML where every reader, human or machine, can find it.
The mistake of treating the ratio as a target
The classic error is reading an old SEO checklist, seeing a recommendation to keep text-to-HTML above some figure, and then padding pages with filler text to hit it. This is backwards. Adding low-value words to game a ratio produces exactly the kind of thin, padded content that the helpful-content systems demote. The ratio is a symptom you read, not a quota you fill.
The right response to a low ratio is to ask which side of the fraction is wrong. If the text is genuinely too thin for the topic, write more, real, useful content. If the text is fine but the code is heavy, trim the code. You almost never fix a low ratio by stuffing keywords or boilerplate; that just trades one quality problem for another.
The ratio as a quick triage across many pages
Where this check earns its keep is triage at scale. Run it across a batch of pages and the outliers jump out: the article that scores like a thin landing page, the product description that is all template and no words, the category page where boilerplate has crowded out the unique content. You are not looking for pages that hit a number; you are looking for pages whose ratio is wildly out of line with their purpose.
Those outliers are your shortlist for a closer read. A genuinely thin page might need to be expanded, merged with a sibling, or removed entirely if it adds nothing. A code-heavy page might need its scripts cleaned up. Either way, the ratio has done the valuable part, pointing your limited attention at the handful of pages that actually need work instead of leaving you to read every one by hand.
Why a clean HTML-to-text balance helps crawlers and AI
Search crawlers and AI bots have to download and parse your HTML to find the content worth indexing or citing. A page that is mostly code costs them more to process and gives back less, and bots running on a crawl budget may not render the JavaScript that would reveal the missing text. Lean HTML with the content present in the raw response is the most crawler-friendly thing you can ship.
AI answer engines in particular reward content they can extract cleanly. When your meaningful text sits in the HTML rather than behind a wall of script, systems like AI Overviews, ChatGPT search, and Perplexity can read, summarize, and cite it without the rendering gymnastics that make a page unreliable to quote. A healthy text-to-HTML balance is a quiet accessibility win for both human readers and machine ones.
How the ratio relates to page weight and speed
A low text ratio and a slow page often share the same root cause: oversized HTML. Every kilobyte of inline script, repeated markup, and padding has to travel down the wire and be parsed by the browser before anything useful happens. So the ratio is not only a content signal; it is an early hint that the document itself is heavier than it needs to be, which shows up later as sluggish load times and worse Core Web Vitals.
That makes the ratio a useful companion to a proper speed or page-weight test rather than a replacement for one. If the ratio is low because of code bloat, the same trimming that lifts it, externalizing scripts, cutting unused markup, deferring third-party tags, also makes the page faster. Treat a poor ratio on a code-heavy page as one symptom of a bigger performance story, and fix the cause once to improve both numbers at the same time.
What to do after you check the ratio
If the ratio is low because of heavy code, move inline scripts and styles into external files, defer non-critical third-party scripts, and lean on your platform to reduce the markup wrapping each element. Audit the tag manager and remove anything firing on every page that does not need to. These changes lift the ratio and speed up the page at the same time, which is the real prize.
If the ratio is low because the page is thin, expand the content with depth that actually serves the reader, examples, specifics, answers to the questions people bring to the page, rather than filler. Then re-run the checker to confirm the balance has shifted in the right direction, and pair it with a page-weight or speed test to make sure the underlying bloat is gone, not just diluted by added words.