joshbuchea/HEAD: a reference list for HTML head elements, and what it does not do
A simple guide to HTML <head> elements
At a glance
- What is it?
- HEAD is a CC0 reference document that enumerates valid head elements, a recommended ordering, and vendor-specific meta tags. It is documentation, not a library, and its value depends on whether you need a checklist or a build-time generator.
- Who is it for?
- Adopt HEAD as a reading reference if you hand-write head markup and want a checklist of meta, link, and script tags with a stated ordering rationale. Do not adopt it if you expect a package, a linter, or generated output: the repository is a document, and the README shows no install step, no CLI, and no build.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 111 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What HEAD is, and the gap it fills
HEAD is a single reference document about the contents of the HTML head element. The README describes it as "A simple guide to HTML `<head>` elements" and the table of contents splits the material into Recommended Minimum, Elements, Recommended Order, Meta, Link, Scripts, Icons, Social, Browsers / Platforms, App Links, Deprecated, and Other Resources. That structure tells you what the project is for: it is a lookup table for people writing head markup by hand, or for people who need to check what a given tag does before adding it.
The problem it solves is fragmentation. Head tags come from several sources that do not share a documentation home: the HTML specification, search engine crawler directives, social card protocols, mobile platform hints, and browser vendor extensions. HEAD collects them in one file. Someone adding a favicon, a canonical URL, and an Open Graph title in the same afternoon would otherwise open four or five separate vendor pages.
Who it is for follows from that. A frontend developer writing a static template, a developer auditing an existing head block for missing tags, and a technical writer who needs a starting point for a custom head. It is not aimed at framework users who never touch head markup directly, because nothing in the repository integrates with a build system.
The recommended minimum, and why the ordering section matters more
The README's Recommended Minimum block is three tags: `meta charset="utf-8"`, `meta name="viewport" content="width=device-width, initial-scale=1"`, and `title`. An HTML comment in the same block states that the two meta tags should come as early as possible in the head to ensure consistent document rendering, and that any other head element should come after them.
The ordering section is the more useful part, because it gives reasons rather than just a list. The README states that `meta charset` must appear within the first 1024 bytes of the document. It places the viewport declaration second so responsive rendering is correct from the start. The title comes third, and the README explains this prevents potential re-rendering. Resource hints (`preconnect`, `dns-prefetch`) come before stylesheets so they have the most time to take effect. Stylesheets come before scripts. Scripts come last, with a note to use `defer` or `async` where possible to avoid blocking rendering.
That is a defensible ordering, and it is the part of the document most likely to change how someone writes a template. The 1024-byte constraint on `meta charset` is a hard browser behaviour, not a style preference, and it is the kind of detail that is easy to violate when a large comment block or an inline script sits at the top of the head. If you take one thing from HEAD, take that constraint and the ordering rationale around it.
How you use it: there is no install step
There is no package to install. The README shows no `npm install`, no CDN script tag, no CLI, and no configuration file. The primary language field in the repository metadata is unknown, which is consistent with a project that is mostly prose and HTML snippets. The homepage listed is htmlhead.dev, and the README links to it, so the intended consumption path is reading the document or the site.
The practical workflow is copy and adapt. A developer takes the Recommended Minimum block, then pulls individual tags from the Meta, Link, Icons, and Social sections as needed. The README gives complete example blocks, for instance the ordering example wraps the full sequence in a single `<head>` element, and the Meta section annotates each tag with an HTML comment explaining its purpose. Several entries include inline guidance, such as the note that `meta http-equiv="Content-Security-Policy"` should be placed as early as possible because it only applies to resources declared after it.
Because it is a document, there is nothing to keep in sync at runtime. That is a real advantage over a generator dependency: no version bump, no lockfile change, no supply chain surface. The trade-off is that nothing enforces the guidance. If a teammate adds a blocking script above the stylesheet, HEAD will not catch it.
The social and platform sections are where the material gets uneven
The Social section is subdivided into Open Graph, Schema.org, Google JSON-LD Schema, Pinterest, OEmbed, QQ/Wechat, Dublin Core, and Fediverse. That spread is the point: social card protocols are not unified, and a page targeting several networks needs tags from more than one of them. Having Open Graph and the JSON-LD variant in the same document saves a round of searching.
The Browsers / Platforms section covers Apple iOS, Google Android, and Google Chrome, and there is a separate Browsers (Chinese) section for 360 Browser, QQ Mobile Browser, and UC Mobile Browser. This is unusual and useful. Most English-language head references stop at Apple and Google, and teams shipping to Chinese mobile browsers often discover the gap late.
The unevenness is the limitation. Vendor tags age at different rates. The README includes a Deprecated section, which is the right instinct, but the material supplied here does not show its contents, so I cannot say how current that list is. The presence of both a Deprecated section and a large set of vendor-specific tags means the reader carries the burden of checking which entries still apply. A tag that a browser vendor dropped two years ago can sit in a reference file indefinitely. Treat every non-standard entry as a claim to verify, not a fact to copy.
Licence: CC0, and what that permits
The README carries a CC0 badge linking to creativecommons.org/publicdomain/zero/1.0/, and the repository metadata supplied here does not list a licence identifier, so CC0 is the only licence statement visible in the material. CC0 is a public domain dedication rather than a permissive licence with conditions. The practical consequence for a documentation project is that copying snippets from HEAD into your own templates, internal style guides, or a commercial product does not carry an attribution requirement.
That matters more than it sounds. Head markup is exactly the kind of thing that gets copied into a starter template and then redistributed, sometimes commercially. A reference under a copyleft documentation licence would create friction at that step. CC0 removes it.
This is not legal advice, and the usual caveat applies: the CC0 dedication covers the text and examples in the repository, not any third-party specification text or vendor documentation the entries may paraphrase. If you are redistributing a large portion of the file verbatim, the licence statement is the thing to check, and it is stated plainly in the README badge.
Where a generated head block beats a reference file
The real alternative for most teams is not another document. It is a build-time generator that emits head tags from structured input. Frameworks such as Next.js and Nuxt expose head management through a component or a config object, and standalone libraries exist that take a title, a description, and an image URL and produce the full set of Open Graph and Twitter card tags.
The difference in approach is enforcement versus enumeration. HEAD tells you what the tags are and in what order they should appear. A generator decides for you: you supply the values, and the library controls the output order, deduplicates tags, and updates them on client-side navigation. If your application is a single-page app where the title and canonical URL change per route, a static reference file cannot help, because the problem is not knowing which tags to write but writing them at the right time.
HEAD still complements a generator. When a library emits something you did not expect, or when you need a tag the library does not support, the reference is where you check the syntax. The two are not substitutes. Choose the generator for runtime correctness and keep HEAD open for the cases the generator does not cover.
A second alternative worth naming is the specification itself. The HTML Living Standard defines which elements are valid in the head, and HEAD's Elements section lists the same set: `meta`, `link`, `title`, `style`, `script`, `noscript`, and `base`. The specification is authoritative and current. HEAD is faster to read and covers vendor tags the specification deliberately excludes. If you need certainty about a standards-track element, read the specification; if you need to know what a crawler directive does, HEAD is the shorter path.
Maintenance cost and what to verify before you rely on it
The maintenance cost of adopting HEAD is close to zero at the repository level and non-zero at the knowledge level. There is no dependency to update, no breaking change to track, and no runtime to monitor. The cost is that the document can drift from browser and crawler behaviour, and the reader is responsible for noticing. The repository metadata shows a last push of 2026-05-28 and no retrieved releases, so the project appears to be maintained through commits to the document rather than through versioned releases. That means there is no changelog to scan for tag removals.
Before relying on a specific entry, check three things. First, whether the tag is standards-track or vendor-specific; the section it appears in tells you. Second, whether it appears in the Deprecated section, whose contents are not visible in the material supplied here. Third, whether the vendor still documents it, since the Meta section includes verification tokens for Google Search Console, Yandex Webmasters, Bing Webmaster Center, Pinterest, and Norton Safe Web, and verification schemes change without notice.
The recommended ordering is the part least likely to rot, because it rests on browser parsing behaviour and the 1024-byte charset constraint rather than on any vendor's current preference. If you adopt one section of HEAD into a team template, adopt that one, and leave the vendor tags as a lookup you perform per project.
Editorial conclusion
Adopt HEAD as a reading reference if you hand-write head markup and want a checklist of meta, link, and script tags with a stated ordering rationale. Do not adopt it if you expect a package, a linter, or generated output: the repository is a document, and the README shows no install step, no CLI, and no build. Before relying on any specific tag, verify it against the current spec or vendor documentation, because the file mixes stable elements with vendor tags and a Deprecated section whose contents are not visible in the material supplied here.
Community notes