All About The HTML Doctype

About This Snippet
So, what is a Doctype? A Doctype is the first line in an HTML, XHTML or XML document which informs a web browser as to what kind of document to expect. This subsequently instructs a web browser as to how to render the document. It would be remiss to not go into some history as to how the Doctype came into existence, but more on that later (see “Geeking Out” below).

Some things to keep in mind:

  • The Doctype is supported in all major browsers (think: Chrome, Edge, Firefox, Safari and Opera).
  • It technically is not an HTML tag, even though it has similar syntax.
  • The older HTML 4.01 Doctype took on multiple scopes (I.e. strict, transitional or frameset) which either permitted or disallowed specific behaviors.
  • Similar to HTML, the Doctype is case-insensitive, but often is notated in all-caps (I.e. DOCTYPE).

The Snippet
For HTML5 use:

<!DOCTYPE html>

(Note: This Doctype is the simplest and most common. It is used for most HTML based applications.)

For Transitional HTML 4.01 use:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

(Note: This Doctype is legacy and permits both presentation and deprecated elements, while disallowing the use of framesets.)

For Frameset HTML 4.01 use:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">

(Note: This Doctype is legacy and permits both presentation and deprecated elements, while also allowing the use of framesets.)

For Strict HTML 4.01 use:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

(Note: This Doctype is legacy and forbids the use of presentation and deprecated elements, as well as framesets.)

For Final HTML 3.2 use:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

(Note: This Doctype is legacy and identifies a document adhering to the HTML 3.2 standard)

For Transitional XHMTL 1.0 use:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

(Note: This Doctype is the XML equivalent of HTML 4.01 Transitional, it requires the use of well-formed XML while also possessing similar features made available with HTML 4.01 Transitional.)

For Strict XHTML 1.0 use:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

(Note: This is the XML equivalent of HTML 4.01 Strict, it requires the use of well-formed XML and adheres to a strict XML specification.)

Geeking Out
Older Doctypes, such as those for HTML4, XHTML and earlier would require what was called a Document Type Definition (DTD), but with the advent of HTML5, this no longer became necessary and was simplified. So, why do we need a Doctype and how did it come into existence? Well, in the early “wild west” days of the Internet, there were somewhat loose standards in place for web browsers to follow in rendering an HTML document (Think HTML 3.2 and earlier). Although specification existed, the manner in which it was implemented wasn’t necessarily consistent from web browser to web browser and this had its affect on how web pages were rendered.

In building out web pages, there were all sorts of quirks that existed and it created a real hassle for early web developers to engineer a web page that could take on a visual aesthetic consistent across web browsers. Sometimes there would be issues where characters would wrap when they weren’t supposed to; issues where certain properties would be adhered to or recognized in one web browser, but not in another (E.g. from that era, Microsoft Internet Explorer versus Netscape Navigator versus Quarterdeck Mosaic).

This landscape of “standards” discontinuity created a real hassle to be reckoned with when building out websites. Although, the Doctype existed all the way back to HTML 2.0, in practice, the Doctype was rarely used in the early days of Web Development. This pattern changed in the mid to late 1990s with the commercialization of the Internet and the introduction of HTML 3.2. With these transitions, it became more common practice to begin including a Doctype in an HTML document.

Moreover, in the late 1990s XML was introduced. Its presence more broadly necessitated web browsers to differentiate the type of document being handled. XML specification had its influences on HTML 4.01 with its attention on the document being well-formed, having stricter rules to adhere to. With this, came the advent of XHTML, which essentially was HTML having been reformulated to adhere to the stricter standards and disciplines of XML. This influence continued throughout the 2000s, up until the point that HTML5 was drafted, specified and published.


SnippetNinja provides articles with snippets on various topics. These articles are written to facilitate education and learning in technology. Click here to read more about SnippetNinja and the content provided on this site.

Copyright © 2024-2025 SnippetNinja.

Creating Custom Error Pages

About This Snippet
We’ve all seen it before, the notorious “404 Not Found”, or perhaps even the “401 Authorization Required” or “403 Forbidden” error pages.

These website error pages or responses, which are actually responses from the underlying HTTP server (that is, web server), almost never look good out-of-the-box relative to the rest of the appearance of a website. Wouldn’t it be nice to freshen these up a bit, so the error pages better match the branding and look-and-feel of your website? Well, here is the snippet to do so…

The Snippet
There are multiple ways to intercept this error and serve up a custom response depending on the HTTP server (E.g. Apache HTTP Server, Nginx, IIS, etc.). For the purpose of this article, we will focus on Apache HTTP Server with its ErrorDocument directive.

(Note: The following snippet provided is in context to those websites running under Apache 2.x, where the “AllowOverride FileInfo” directive has been given for the virtual host, enabling the use of .htaccess files within your web root. This is most often enabled already in shared hosting environments. If you are self-hosting, you may require some additional setup.)

In order to perform this action you will need:

1 ) A file with HTML content that will hold your custom response. For this example snippet create a file named 404.html. Within this file create the custom HTML content you wish to be presented when a “404 Not Found” response is given from Apache HTTP Server and place it in the location:
“<web-root>/errors” of your web host. An example might be “public_html/errors”.

2 ) The ability to add/edit the .htaccess file typically found in your web root folder. An example might be “public_html/.htaccess”.

Once steps 1 and 2 are completed above, open your .htaccess file and simply add the following line:
ErrorDocument 404 /errors/404.html

That’s it! In your web browser go to a location that does not exist on your site and you should see rendered a page that is the contents of your 404.html. Click here for an example of this setup on www.snippetninja.com. (NOTE: a fake URL has been linked to in this example link above to trigger the “404 Not Found” error response using a custom page).

Geeking Out
Other status codes can have custom responses as well. By simply replacing the number “404” in the example above to a “401” or “403”, and then adding a custom page of your choosing (E.g. 401.html or 403.html), you can then provide a separately handled presentation for that HTTP error response.

How does this all work? When someone makes a request from your website with a web browser, the HTTP server that hosts your website looks for that resource (E.g. /some-web-page.php). If that resource is found, it returns the contents of that resource back to the web browser along with some other useful HTTP header information such as content-type and the status code (just to mention a few). If successful, the status code is returned with the message “Status: 200 OK”. However, when a resource is not found, the status code “Status: 404 Not Found” is returned and the HTTP server pulls its default “canned” page for this event, which looks something like this:

404 Not Found HTTP status code

A response back with a page that appears this way typically does not look good visually in relation to the look-and-feel of a website, and as result, breaks the visual design continuity. The good news is most all HTTP servers provide a way to override the “canned” default and alternately serve up a user-defined custom page, putting control back into your hands over the visual presentation of your website!


SnippetNinja provides articles with snippets on various topics. These articles are written to facilitate education and learning in technology. Click here to read more about SnippetNinja and the content provided on this site.

Copyright © 2024-2025 SnippetNinja.