Only 2.6% of the most visited websites have fully valid HTML

theo_dcrx 40 points 55 comments August 12, 2026
validatehtml.com · View on Hacker News

Discussion Highlights (20 comments)

cyanbane

I would def argue this is a feature of the net ( that people from all walks of browsers can see mostly the same thing ) and not a bug.

hodder

And not a single person cares. What does fully valid even mean anymore?

blakesterz

"Accessibility failures are near-universal." Why does it seem like Accessibility is always an after thought? It is usually so easy to do while a site is built. We just don't think about it until someone complains?

collabs

I would be interested to see if the metric moves meaningfully based on switching to a different set of parameters for example running from the US vs the EU and multiple attempts over multiple days to see if anything changes...

rogix

At this point, with all the tools available, if your site does not have fully valid HTML, it is because you don't care. LLMs are your friends, dev.

personalityson

HN is not one of them https://validator.w3.org/nu/?doc=https%3A%2F%2Fnews.ycombina...

alt227

This is exactly why HTML is so ubiquitous, because it is so tolerant of mistakes in formatting, syntax, and just about anything else. Most browsers will even read and process most of the things listed on this page because even if the spec doesnt say so, it just makes sense to anyway.

JSR_FDED

50% of my errors are “<font> is deprecated”. If browsers stop supporting that I’m guessing huge swathes of the web will be affected, so I’m guessing it will never happen.

mervz

Legit who cares? It's not stopping people from visiting them

INTPenis

As someone who valued that "Validated by w3c" button on my website back in the day, if a website today has FULLY valid HTML, I gaurantee you the admin is a massive nerd.

shevy-java

The question is how important it is to have fully valid HTML. The HTML validator complains about a ton of useless crap IMO. At one point I simply gave up on that. Just blindly adhering to that validator makes little sense really.

simonw

<img> is missing required "src" attribute On 1,093 sites, 41.2% of the sample?

zbentley

I wonder how many of them only work because of things like https://github.com/WebKit/WebKit/blob/main/Source/WebCore/pa... Which overlaps with, but isn't the same as, JS quirks mode.

teo_zero

> An unclosed tag occurs when an opening HTML tag like <div>, <p>, or <span> is missing its corresponding closing tag. Since when does <p> requires a closing tag? Note that TFA lists this among "spec violations" and not merely "best practices".

wild_pointer

Honestly more than I thought

account42

The claim in the title does not match the linked website. The 2.6% figure only includes websites that also follow some arbitrary set of "best practices" in addition to being valid HTML, some of which actually contradict best practices from the past.

jerf

To a first approximation, this doesn't matter anymore. "Valid HTML" used to be a big deal because when you left the HTML spec you were inviting the various browsers to interpret your non-standard HTML in differing ways, sometimes quite catastrophically so for the styling or how the Javascript would interact with the page. This is no longer anywhere near as important as it used to be because HTML5 defines a method for turning more-or-less any sequence of bytes into the same DOM tree: https://dev.w3.org/html5/spec-LC/parsing.html And that's only the beginning of the process. I can't seem to find a good link to the whole 8.2 section of the HTML5 spec but the whole process is freaking huge. But it's defined now. I hedge on the "more-or-less" because I'm sure there are still bugs in various parsers and perhaps there are pathological sequences that wouldn't be handled by this process, but such sequences would be very, very distant from being HTML at all. But one difference with HTML5 is that the parsers would be considered buggy; in previous versions it could be debatable what the parser should do. HTML5 should fully specify that. If it doesn't that is now a bug in the spec. I would hope it has been banged on enough at this point that any possible remaining corner cases must be pretty small by now. It is in my considered opinion perfectly sensible to define "HTML" as "what comes out of the HTML5 parsing process" and not really be all that worried about whether this tag does or does not need to be closed before this set of tags but not this other set of tags. It is no longer such an invitation to the browsers to render things completely differently. What was once an academic concern and a user-experience concern is now largely an academic concern. In fact, if you're handling HTML5 correctly, which is to say, using a real, conformant parser to operate on the resulting parse tree rather than trying to handle it as a string... you can't even tell the difference between "valid" and "invalid" HTML anymore! The parser will wipe that away entirely before the HTML gets to your code. That's how important it is now.

ef2k

The number is eye-catching but it's measuring how non-conforming the source code is, as opposed to whether it results in the intended DOM. This is why HTML validators largely went out fashion since it's more practical to consider source "valid" if it renders correctly in the browser. The way the browser handles non-conforming source code is part of the spec [1]. [1] https://html.spec.whatwg.org/multipage/parsing.html#parse-er...

xyst

hn receives a "D" grade with 139 errors, 37 warnings Someone has been slacking in the self proclaimed "hacker" news feed

gkolli

As an aside, what is up with the design of clearly vibe-coded websites? You can tell it's AI from intuition, but is there a list of "tells"? Like black background, gradient text, font? Would love to learn more and how to combat

Semantic search powered by Rivestack pgvector
4,128 stories · 37,281 chunks indexed