Open any modern webpage and you'll find two things living in it: the words you actually read, and the machinery that makes those words appear. That machinery — HTML tags, CSS, JavaScript — can balloon fast. The relationship between the two is what we call the code-to-text ratio.
It's one of those metrics SEO folks love to argue about: not a ranking factor, yet somehow still important. Let's unpack what it means, how to calculate it, and what to do when yours looks lopsided.
Simply put, it's the percentage of a page's content that is real, visible text versus everything else: HTML markup, inline styles, JavaScript, comments, and metadata.
Say a page is 100 KB in total. If 30 KB is readable text and the other 70 KB is code, the ratio is 30% — a rough measure of how "heavy" your page is relative to the substance it delivers.
Google has never published this as an official ranking factor, but that doesn't make it irrelevant. The ratio is a useful proxy for something Google does care about: page quality and crawl efficiency. A page buried under mountains of scripts with barely any text looks thin, and crawlers have to work harder to figure it out.
The formula is simple:
Text-to-code ratio = (Visible text size ÷ Total page size) × 100
So if your HTML file is 80 KB and the plain text a visitor reads amounts to 24 KB, you're sitting at 30%.
Note the ratio is usually calculated on the page source (the HTML document itself), not every external resource the browser downloads. That's why a source-code analysis is the most honest way to measure it.
Here's the number everyone wants: roughly 25% to 70% is the commonly cited healthy range.
Below 25% usually means the page carries a lot of code weight for very little readable content — heavy scripts, bloated frameworks, or auto-generated markup padding out a page that says little. Above 70% is rare and generally fine; those tend to be long-form articles with clean markup.
But this is a guideline, not a rule. A product page with a complex layout might legitimately sit at 15% and still rank beautifully if the content is strong and the page loads fast. Conversely, a page at 50% with a slow server response is still a slow page.
Think of the ratio as a diagnostic light on your dashboard, not a traffic ticket. When it's low, go look at why.
A low code to text ratio usually points to code bloat, and bloat causes real, concrete problems:
Search engine bots get a finite amount of time per site — your crawl budget. If every page forces Googlebot to chew through 500 KB of JavaScript and inline styles to find 50 KB of text, your budget goes to parsing instead of discovering. Big sites feel this most: bloated pages mean fewer pages crawled per visit, so new content gets indexed slower.
Heavy pages — huge HTML documents, unminified CSS, stacks of render-blocking scripts — take longer to download and parse. Page speed is a confirmed ranking factor, and it's one of the biggest drivers of user experience. A visitor on a mid-range phone in a low-bandwidth area doesn't care about your elegant code — they care whether the page loads.
When Google strips away the code, a bloated page with little text can resemble a thin-content page. The ratio itself doesn't cause a penalty, but the underlying reality — lots of machinery, little substance — is exactly what algorithms tuned to surface quality content are designed to catch.
Bloated markup full of leftover scripts, commented-out sections, and unused styles is harder to debug, slower to update, and more fragile. Every unnecessary script is another dependency that can break.
If you suspect your pages are carrying extra weight, a page size checker is a good companion diagnostic — it tells you how much data your page actually transfers, the other half of the bloat story.
You have a few options, ranging from manual to one-click:
Manual inspection. View the page source (Ctrl+U / Cmd+U), copy the full HTML, and estimate text versus markup with a text tool. Works for a one-off; painful for a site-wide audit.
Developer tools. Browser dev tools show raw HTML size, and extensions can strip tags to approximate text size. Better, but still manual.
Dedicated tools automate the whole thing: paste a URL, get the ratio, text size, and HTML size in seconds. Try the code to text ratio checker — free, no signup, no setup.
For a deeper look at exactly what code is bloating your pages, get the source code of a webpage and scan it directly — three nested divs where one would do, scripts loading dead libraries, and all.
If your ratio comes back low, here are the fixes that move the needle:
Stripping whitespace, comments, and redundant characters from HTML, CSS, and JavaScript doesn't change what the page does, but it can shave 10–30% off your code weight. Most build tools and CMS plugins do this automatically — if yours doesn't, turn it on.
Audits consistently find pages loading entire JavaScript libraries for one feature, or theme CSS where 90% of the rules never apply. Check what each script actually does — if a plugin isn't being used, remove it, don't just deactivate it.
Modern semantic markup (<article>, <nav>, <main>, <section>) is leaner than old div-soup and communicates structure to search engines more clearly. Swapping six nested <div>s for one semantic element cuts code and improves comprehension.
Huge blocks of inline CSS and JavaScript inflate the HTML document itself. Moving them to external files lets browsers cache those resources, so returning visitors load less.
Developers love comments — in the codebase. But shipped HTML full of <!-- TODO: fix this later --> notes and dead code is dead weight for every visitor and every crawl. Your minifier should strip these automatically.
JSON-LD is great for SEO, but some implementations paste enormous schema blocks into every page. Keep it relevant and compact — include what the page needs, nothing more.
Is code to text ratio a Google ranking factor? Not directly. Google has never listed it as a ranking factor. But the things that produce a low ratio — heavy pages, slow loads, thin content relative to code — do affect rankings and crawl efficiency. Treat it as a diagnostic, not a target.
What is a good code to text ratio? Roughly 25% to 70% is considered healthy. Below 25% suggests the page may be bloated relative to its content. It's a guideline, not a hard rule — context matters more than the exact number.
How can I check my code to text ratio for free? Paste a URL into the code to text ratio checker — free, no signup — and you get the ratio plus a text-vs-code breakdown instantly.
Does JavaScript affect my code to text ratio? Yes. JavaScript in the page source counts as code, so pages with heavy inline scripts show a lower ratio — another reason to move scripts to external files and remove any you're not using.
Will improving my ratio automatically boost my rankings? No — there's no direct boost tied to the number. But the fixes that improve the ratio (faster pages, cleaner markup, less bloat) improve page speed, user experience, and crawl efficiency, and those do move the needle.
You don't need to guess whether your pages carry too much code weight. Run a URL through the code to text ratio checker — free, instant, no signup. If the number comes back low, you now know exactly what to fix.
