I recently read a great resource by the Opera developers, entitled, "Introduction to The Web Standards Curriculum". I thought the articles put forth some good reasons why you should look at validating your website, but I realize that not everyone validates their sites, including most of the big names (Google for instance). Do you validate your sites? Have you ever had an instance where not validating your site has hurt you or your company? For you and/or your company, is validation worth the time and money? How do you evaluate its worth to your company? Do you care? And, perhaps most importantly, why or why not?

+3  A: 

I validate both my HTML and CSS, because it helps with debugging display issues a lot. If your HTML is invalid, the browser has to make a "best guess" at what your HTML is supposed to do. I also find the HTML/CSS much easier to work with if it's valid. Working with broken web pages can be a pain, because adding stuff to them often makes things that worked before look suddenly break down because the browser decides it doesn't like it.

+6  A: 

Yes I validate all the pages on my website. I use: and I have a link to the validator at the bottom of every page on my site so I can just click on the link and validate that exact page.

If you use Firefox, you can install an extension that automatically validates pages you visit. It provides a nice little icon in the status area so you don't have to manually validate everything.
John Millikin
The Web Developer toolbar also does that, among many other things
+1 for Web Developer
Cristian Ciupitu
+4  A: 

Have you ever had an instance where not validating your site has hurt you or your company?

Not in the short term, but definitely over a longer time period, as far as maintenance is concerned.

We have had a site which has never validated, and has several layers of tables nested within tables, nested within tables, etc. It's been known to happen that a change has been required to this code which seems innocuous enough but ends up completely breaking the existing layout and requiring far more time and effort than we initially budgeted for to fix, and make sure it's correct in all supported browsers.

So for all of our current projects, we have found that it is absolutely worth the time and effort on any non-trivial webpage (more than 1 table, 1 input) to make sure that it validates.

It also makes it easier to find and fix any cross-browser display issues, and generally makes our maintenance far more manageable.

+4  A: 


I don't care what the validator says. I only care if it renders correctly in all the major browsers, and the validator doesn't check for browser errors.

Maybe someday the validator will be enough, but I'm not holding my breath.

Jonathan Allen
Could you also specify those major browsers, to make the answer more precise?
Cristian Ciupitu
How do you ensure that your invalid pages will render correctly in future versions of browsers?
1. I won't specify a list of browsers because it varies from project to project and with time.2. I don't worry about future proofing, as there isn't a way to predict how they will behave anyways.
Jonathan Allen
"Renders correctly" is a crapshoot if you're writing out-of-spec code. Basically, you're counting on the browsers to know what you mean.
Just Some Guy
I hardly see why he is down voted for expressing his opinion. W3C Validation doesn't mean your site is going to behave correctly for all browsers past, present or future. It's nice to throw the W3C tag on your page like some sort of merit badge, but your non-IT user doesn't care.
I have to agree with Grauenwolf- For me it is more important to hit my "audience", then to follow a standard "just to get the banner button". Now, if all browsers had rendered pages the same, and followed the validation standard, I would validate, but untill then, I create websites for my visitors.
Israr Khan
I tend to try to write valid markup, but I must agree with HBoss here - there's no reference implementation from the W3C, and nobody really knows what the page should actually "look like" in the browser based on the spec. Thus, testing to ensure it looks right in all the relevant platforms is still essential, and no amount of "correct" markup will make up for that.
Wasn't Amaya supposed to be a reference implementation back in the day? I haven't used it for years so correct me if I'm wrong.
I've never heard of Amaya being anything but a test bed. These days the idea of a reference implementation doesn't exist (if it ever did, it has been replaced by 'two independent implementations')
David Dorward
+22  A: 

For me, validation is an integral part of the website development process, much like debugging/testing is for conventional development.

Perhaps a better comparison would be applying style guides to one's code. There are tools – FxCop for .NET – that verify conformance to programming guidelines. Many enterprises find it important to have this verification as a hard requirement. But I believe validating HTML is even more important because it gives a more direct feedback: If the validator detects an error in the website, this is almost always a real, unintentional error. Unfortunately, such errors often go undetected for a very long time. Then you change something (seemingly) unrelated and everything breaks down.

Cross-browser HTML design is complicated enough as it is. I believe in getting all the help that I can. … apart from all the other arguments that speak for producing conforming HTML code.

Furthermore, I don't know a single argument that speaks against valid markup1 so even if there weren't so many arguments speaking for it, validating markup wouldn't harm.

1) Well, there are “arguments”; however, most “arguments” brought forth are trivially proven wrong and none are supported by empirical data.

Konrad Rudolph
+1: validation helps A LOT towards cross browser sites. Most unexpected browser behaviour is because each browser tries to make the gazillion of bad sites out there work in the way they think is best
An even better comparison would be that validation is like compiling. It checks for syntax errors. (Not that that’s the purpose of compiling, but the comparison stands.) It’s just that browsers will actually attempt to “run” (i.e. display) HTML that doesn’t “compile” (i.e. validate).
Paul D. Waite
@Paul: *I* agree that compiling is an integral part of developing but many people don’t, especially web developers (look at the surrounding field of languages: PHP, Ruby, Perl, Python, none of which has (explicit) compiling). So I don’t think this comparison would be quite as compelling (nor as compiling). ;-)
Konrad Rudolph
Heh! Well, the dynamic languages do get compiled (in Python’s case), or at least run, and if you’ve got a syntax error then, they’ll barf. But yeah, that does make the comparison a bit unhelpful.
Paul D. Waite
+2  A: 

We do XHTML and CSS validation for all websites that we do. We find this important not only for maintenance reasons but to help us to be sure that we are not violating any accessibility standards that can be easily addressed. We would had to alienate some customers just because we weren't making our pages compliant. Nothing makes people more upset than if you ignore the obvious and cause them to have accessibility issues.

Of course, accessibility goes far beyond standards and validation but it is a critical concern in any validation discussion.

Scott Alan Miller
+6  A: 

I validate my personal sites from time to time. To me the incentive is mostly the vanity of knowing that what I put together don't have any obvious, embarrasing mistakes.

I've got a couple of very simple bookmarklets that makes it easy to check the HTML/CSS of the current page, that I use:



And what do you do if you are in a private section of the site? For example, a section that requires the user to login.
Cristian Ciupitu
You could use firefox's webdeveloper toolbar for that. It also knows how to validate local files
Cristian: if I don't want to send the HTML "outside" I install w3c's validator locally. It is free software (packaged in Debian, for instance).
You can also upload HTML files to the validator. Opera has a shortcut for doing that.
It's embarrassing only when other "nerds" see your page isn't valid html!!
HBoss: or when the (archived) page is unparsable in 20 years time.
+1  A: 

I do validate all CSS and HTML on my websites. I usually do this as a last step before release, just to make sure I haven't forgotten anything. Heck, some of my clients actually requested it in the past.

Sometimes I also uses validation as a "debugging" tool: Nesting error or forgotten closing tags on complex pages can causes the most horrible display bugs.

+2  A: 

Would, but the validators return too many useless errors to make it worth my time.

Frankly, if a feature works in all browsers then it is going to get used, that boat has sailed. For instance back before CSS I would put row height in the TR, it works, it is easier than in each TD. Not in the standard? Well it is now, half the world is using it.

Now give me a validator that tells me about thing that are actually broken in browsers (not just paper specs) and you've got something worth using.

--- Hey: don't mod me down just because you don't like my answer. The guy asked if people validate their web sties, not if validating you web site is the best possible practice. A "No I don't" answer is just as valid as "Yes I do."

You might want to take a look at CSS. Blaming a technique you don't fully understand is rather counter-productive.
Konrad Rudolph
Dude, of course I know about CSS, and yes controlling height even in a TD is deprecated. None the less, the point is valid: the validators need to respect the standard that is.
The validators need to respect your "tweaked" standard? That's not how standards work I'm afraid. You follow the standards, not the other way around. Besides that, this seems to validate okay XHTML 1.0:
Hey -- the question was "Do you validate you websites" and I'm getting voted down for having answered the question, "No, I don't." WTF? If the guy only wanted to read "Yes Sir" type answers he would have posted "do you like candy?"
I voted you down not for your answer, but your rationale. Putting a height on a tr is bad practice... it's disallowed in the standard because there are better ways to do it. Just because "everyone" does it, *doesn't* make it the right way.
Neil Williams
Ah, ok that is fine then. But just for the record I don't do that sort of thing in the current world of CSS, that was just an example of where validators have left me wanting in the past.
+1 Jeff, standards should be flexible and based on real world use. That's how "standards" (ugh) came to exist in the first place.
+6  A: 

I validate as a matter of principle.

As far as the need to validate goes, I think it is unnecessary if you already know that your site will work for your demographic. However, without validation we're just regressing back to the IE ages when all we cared about was making our sites work in the popular browsers. There's something hypocritical about complaining about IE and its lack of standards when you don't choose to validate against them.

+4  A: 

I do validate my sites and I think most people should. However, whether you choose to pay attention to what the validator says is another matter. During the early stages of building HTML and CSS, not validating your markup and CSS can cause lots of headaches. A valid page is more likely to work cross-browser and easier to debug when it doesn't.

But does the end result have to validate? Not necessarily, no. Theres plenty of legitimate reasons for not validating. Whats important is to be sure that you're doing it for one of those reasons, just saying "doesn't validate, who cares" isn't really good enough. Its better to say "yeah, I know that part of the page over there doesn't validate because of xx tag/attribute, I concluded doing it like that was the best way to achieve y effect".

So, my advice: run your pages through a validator often, understand what the results mean if it doesn't validate. If once you understand them you're still happy, leave it. If you don't understand them or you don't feel you can justify them, then you may need to rethink.

+1  A: 

I generally validate template or high-traffic pages regularly, other pages from time to time. More than anything, I just use it as a sanity check.

The problem out in industry, though, is the supposing that just because a webpage validates, it is also accessible. This is gravely wrong. I would advise having a much stronger focus on human inspection of correct semantic markup.

Whether or not a deprecated tag or attribute or browser-specific css is being used is actually relatively trivial an issue. What's more important is that the site is accessible and that semantic markup is being used throughout. This, however, can only be assessed by human inspection.

+2  A: 

I also try to validate everything because I find that my cross-browser issues are generally fewer if the page is valid. Usually there are only 1-2 fixes for Internet Explorer 7, if any, and maybe 5-6 for Internet Explorer 6. What I find most useful in writing valid code, though, is keeping the CSS and HTML simple. It doesn't mean that the layout can't be fancy, but if the code feels like it's a hack, usually there's a simpler way.


I always validate my code, doing this means I don't have to hack the css for "IE6" only fixes. I haven't used an IE hacked CSS in about a year and a half and wont ever again. In my experience so far, only poorly structured code (html, xhtml and css) needs to have the hacks in it.


+6  A: 

I think of it this way. There are only two kinds of HTML: valid and non-valid.

With valid code, we know what the browser is supposed to do with it.

With invalid code, we can't possibly know, because there's precisely one way to be valid, and an infinite number of ways to be invalid.

If a particular browser can't display your valid code correctly, you still have problems. But it's a much smaller set of problems.

+3  A: 

Have you ever had an instance where not validating your site has hurt you or your company?

Where I work, our web application has been under development since the days of IE 5. Moving forward we never validated our site or updated existing pages to validate against current browser standards. As a result the site only works in IE, and only when Quirks Mode is enabled.

No other browsers can run the site. The site is also limited in the amount of new "Web 2.0" or "ajaxy" features that can be included because of the fact that many of them rely on Standards Mode, which can't be turned on because they would break existing parts of the site.

Generally I recommend always developing to standard technologies. It will ensure that things will work in the future. Sure, there may be bugs with existing browsers, but bugs are almost always guaranteed to be fixed eventually.

If there are bugs with existing browsers, try to find workarounds, or hacks for those specific bugs, but make sure they're "modular" so that you can remove them or limit them once they are fixed by the browser.

Dan Herbert

I have the XHTML Validation plugin for Firefox so that I can immediately see if there's an error on a page. If I'm going to complain about IE's standards compliance, I can at least avoid being hypocritical and actually following coding standards myself.

Over time this has had the added bonus of having fewer and fewer issues between browsers.

+1  A: 

Another thing to consider, screen readers for people with disabilities.

There is a plug-in for Firefox that allows you to test your site and it is free.

Most other alternatives cost money.

This is called firevox:


I put these links on my pages:

And, I fix any errors they report.

However, I do not strictly rely on those checks. I also validate my pages against the major browsers.

I think standards are important. If your pages are compliant with the standards, they are more likely to work properly on the browsers you do not check against.

Just a nit-pick - testing your pages against major browsers is a great idea, but it's not validation. Validation is a formal check against a DTD, nothing more and nothing less.
Sherm Pendley
Yes, I should have said, "I also test my pages with the major browsers."

I always use validation, however I do not always follow it. There's a difference between following the rules and staying sane.

Imho validation is good because

  • It helps all people that work with the code understand it, as validation is the common point of reference.
  • It helps you become better at understanding concepts and you own code thus making you a better coder.
  • It helps you from writing a billion nested divs, forgetting an end tag somewhere making the whole layout a mess(Once had to debug a billion lines of poorly written code with a billion lines of nested divs, which had not taken a billion years if the person who wrote that code had used validation.)

On the other hand

  • Validation does not always mean that your code will display the way you want it, thus there's always a trade-of as with all standards.

A good validator is HTML validator plugin for FF which lets you do everyting in realtime instead of copying the code to some online validator. It's located here

Reed Richards
+1  A: 

I always validate the websites we create. I want the sites to validate as strict XHTML.

CSS on the other hand is a little bit different for me. I obviously fix the most obvious errors, but sometimes I include things that doesn't validate: things like filter-properties so stuff works in IE6.

I've started doing server side user agent checks and including an IE6 stylesheet lately, as this makes it easier to create a site that at least validates for the GOOD browsers ;)

If I were to look for a new job and saw an opening at a web development company, I'd take a look at their website, and I usually check the source and/or validate their site as sort of a quick measure on how "serious" they are about creating good clean code. I might be going a bit overboard, not many people would do this, but for me, it represents good clean code and the quality of the developers behind the code.

I don't hold hobby sites to the same standard, but I do expect anyone who claims to be a professional, and charges pro-level prices, to deliver pro-quality work, and I expect their own site to represent the best they can do.
Sherm Pendley
+1  A: 

Interestingly, Opera just released a report that finds that most websites don't validate. Out of approximately 3.5 million sites surveyed, only 4.13% of the sites had valid markup. Their MAMA survey has quite a few more interesting findings that you should take a look at if you get a chance.

And people modded me down for observing the same thing.
Probably those who don't validate are too busy trying to fix their website to come to StackOverflow to say "no."
+1  A: 

Yes, I validate HTML, I use -Wall when I'm writing C code, and I use the strict and warnings modules when I'm writing Perl. Why? Because I take pride in my work, and I want to do it well. IMHO, "good enough" isn't good enough.

Sherm Pendley

I feel from a matter of archival integrity it is necessary to be standards compliant. Besides that- it is function of work cost and risk. Any developer who has the pride and the time will make sure things are complete. Developer without time and simply wants to get work done to get a pay check may never have even considered validation.


I find the running my code through a validator is useful for checking whether I've made any obvious mistakes. However, since I sometimes use non-standard elements (such as Apple's special search box: <input type="search" />), I don't aim to get a page 100% 'valid'—I just try to fix any problems that don't need to be there.


Steve Harrison
+1  A: 

XHTML Strict. Always. There is no excuse to not validate. Lack of validation shows laziness. Nothing more nothing less. You don't have to advertise it to the world that your site is valid, but you should take the extra couple minutes DURING development to keep it valid. Once you start validating your code, you will gain the habit of keeping it valid. After a very short time, it will become second nature and your validation will become 1st nature.

+2  A: 

I always go out of my way to make sure my HTML and CSS is valid. I always revalidate after changing anything. It seems to help reduce cross browser compatibility issues. However, I only validate as 4.01 transitional.

+1  A: 

I once forgot a > in a site. It didn't have any impact in Firefox and it was much later that I noticed that the site totally broke in IE. A simple validation would have caught that error.

To make validating easier, I built


I validate the code. But when developers take the html pages for coding, they remove html tags and add jsp, jsf tags. I am not sure if they real care to validate after adding those tags.


Yes, validating web sites you author is usually good practice. I've found the following Firefox extensions handy in doing so.

The W3C HTML validator is helpful as well.

One cool site is, which is a front end for the various W3C validators. You give it a URL and let it discover all the bits that it can validate, like CSS, HTML and RSS feeds. If you create an account you can save your list of sites and pages with a handy keyword. Check out the one for Stack Overflow.

Jonathon Watney

I've recently finished a site where XHTML strict was a requirement. All the guys on the team were using Firefox add-ins, and more recently dev tools in IE, to validate against the W3C engine. Even then, too high a proportion of bugs that made it into test would have been caught earlier if we could have guaranteed everyone always validated (including different data conditions in the CMS). Now I'm looking at automating it. I've got HTML tidy running from a unit test runner, and I'm considering running a spider to do the job more thoroughly.

Why? Well apart from it being one of the project requirements, it also gave us lots of good feedback that prevented problems. The huge majority of rendering/CSS bugs were solved immediately once we fixed the html that hadn't validated. What's not to like?

Dominic Cronin
+2  A: 

you ever had an instance where not validating your site has hurt you or your company?

One of our clients was slated in the press for having non-conformant HTML. It was basically an article in a trade journal where some jumped-up "web consultant" was touting for work by publichsing an article comparing the web sites of leading companies [in that field] - well, that's my take on the matter!, but naturally our client wasn't happy that they were marked down for "poor quality HTML". Best as I can guess it (from looking at other sites in the article, and how they were "marked") all that had been done was to create a score based on the number of HTML Validtor errors.

I guess its fair to say that up until then we had been doing what another poster here mentioned: "Just make sure it renders correctly in all browsers". We did use HTML Validator, but only to look for goofy things that we had overlooked, not to be completely anal about it.

However, since this episode that policy has changed!

That's definitely a worst-case scenario, outside of not being able to use the site.