Content-to-Code Ratio Checker
How much of the bytes you ship is the thing people came for.
View the page source in your browser (Ctrl+U or ⌘+U) and paste the whole thing. Nothing is uploaded.
Where the bytes go
| Component | Bytes | Share |
|---|
Observations
What the content-to-Code Ratio Checker does
The content-to-code ratio is the proportion of a page's bytes that are visible text rather than markup, script and style. It is a diagnostic measure, and it is worth saying plainly at the start: it is not a ranking factor. Google has never used it and has said so directly. Any tool presenting a target percentage as an SEO requirement is selling something.
What it is useful for is spotting bloat. A page with 250 words of content and 400 KB of HTML is telling you something — usually that a page builder is generating dozens of nested wrapper divs per paragraph, that a whole stylesheet has been inlined into the head, or that the template carries a large block of comments into production.
This checker breaks the bytes down rather than just producing a percentage. It separates visible text from HTML markup, inline scripts, inline styles, inline SVG and comments, so you can see where the weight actually is. It then looks for the specific patterns that cause a low ratio: heavy inline style attributes, more inline script than text, deep div nesting with few semantic elements, and the very long class lists that utility-first CSS frameworks produce.
The last of those is worth a note. A utility-class framework can push the ratio into single figures and is not thereby a problem — it is a deliberate trade of markup size for stylesheet size and development speed. Read a low ratio as a question, not a verdict: is the page thin, or is the template heavy? Those need entirely different responses.
How to use it
- Paste your page's HTML source.
- Look at the byte breakdown before the percentage — it tells you where the weight is.
- Work through the observations. Comments and inline styles are usually the easiest wins.
- If the word count is low, the content is the issue rather than the markup.
A worked example
Two pages with a similar ratio and completely different problems:
| Page A | Page B | |
|---|---|---|
| Ratio | 4.2% | 4.8% |
| Visible text | 1.2 KB (180 words) | 11 KB (1,800 words) |
| Total HTML | 29 KB | 230 KB |
| Diagnosis | Thin content | Bloated template |
The percentages are nearly identical and the fixes have nothing in common. Page A needs writing; its template is fine. Page B has plenty to say and is wrapping it in 219 KB of markup, which is a build problem. This is exactly why the ratio on its own is close to useless and the byte breakdown is not.
Frequently asked questions
Is content-to-code ratio a Google ranking factor?
No. Google has stated it does not use this measure. It persists in SEO tooling because it was easy to compute in the early 2000s. Use it as a diagnostic for page bloat, never as a target.
What ratio should I aim for?
There is no correct figure. Traditional advice quoted 25% or more, which is unattainable for most modern sites and meaningless anyway. Above roughly 10% is comfortable; below 5% is worth investigating, but investigate rather than assuming a problem.
My framework produces a very low ratio. Is that bad?
Not necessarily. Utility-first CSS frameworks trade long class attributes for a smaller stylesheet, and component frameworks add wrapper elements. Both are legitimate. What matters is the total transfer size and rendering performance, not the ratio.
Does a higher ratio make pages faster?
Indirectly and weakly. Less markup means fewer bytes to transfer and parse, but images, fonts and JavaScript dominate real page weight by a wide margin. Optimise those first; markup size is rarely the bottleneck.