Online Tool Store
AMP Validator
Check AMP HTML for required head markup, the 75 KB CSS budget, disallowed tags and inline styles, and missing extension scripts in your browser.
🔒 This tool runs entirely in your browser. Your files are never uploaded to a server.
Example shown — it contains several deliberate errors.
—
Findings
How to use it
- Paste your AMP HTML, or open the file from disk.
- Work through the errors — they are the ones that block validation.
- Watch the CSS bar; it is the limit that creeps up on you.
- Confirm with the official validator before you publish.
What can honestly be checked in a browser
AMP conformance is defined by a generated ruleset listing every permitted tag, attribute and value combination. It is large, it changes, and it lives on the AMP project's servers — so a page that runs entirely in your browser cannot claim to have validated anything against it. Rather than pretend, this checks the subset that is genuinely local:
checked here doctype, ⚡ attribute, charset and its position,
v0.js and its async, canonical, viewport,
boilerplate, CSS budget, !important,
replaced tags, inline styles, author scripts,
on* handlers, missing extension scripts
not checked per-component attribute rules, layout validity,
anything needing the live ruleset
That left-hand list is not a consolation prize — it is where the great majority of real AMP errors live, particularly when converting an existing page.
The rules that catch people out
Inline styles are banned. Not discouraged — disallowed. Every
declaration has to move into the single amp-custom block, and a template that emits
style="..." anywhere will fail.
Charset must be first. Not present — first child of head. A title tag or an HTML comment above it is an error, and it is the kind of thing a templating system introduces without anyone noticing.
!important is disallowed in author CSS, because the runtime relies on being able to override layout properties. A single one anywhere in 75 KB of stylesheet fails the page.
Using a component is not declaring it. Writing
<amp-carousel> without its
custom-element script in the head is an error, and the visible symptom
is simply that the component never appears. The tool cross-references every component used against the scripts declared.
Why the CSS budget gets its own bar
Most AMP errors are binary: the tag is there or it is not. The 75,000-byte author stylesheet limit is different — you approach it gradually across months of small additions and then one commit tips it over, failing a page that has been valid for a year. Showing the current usage as a proportion turns it from a trap into a number you can watch. Note that it is measured in bytes rather than characters, so non-ASCII content in content strings counts for more than it looks.
A word about AMP itself
The main reason to adopt AMP was preferential placement in search results, and that requirement was dropped — top stories no longer depends on it. If you maintain existing AMP pages, keeping them valid is still worth doing, and this helps. If you are considering AMP for something new, the honest advice is to weigh it against simply building a fast page, because the format's constraints are considerable and its main incentive has gone.
FAQ
Is this the official AMP validator?
No, and it says so on the page. Official conformance is defined by a large generated ruleset published by the AMP project, which has to be fetched — so nothing running purely in your browser can be the authority. This checks the mandatory structure, the CSS budget and the commonly broken tag and attribute rules locally, which catches most real errors before you get that far.
What can it check, and what can it not?
It checks the required head markup, the boilerplate, the author CSS byte budget, disallowed tags, inline styles, custom scripts, event handlers, and missing extension scripts for the components you used. It cannot check the full per-attribute rules for every AMP component, layout validity in detail, or anything requiring the live ruleset.
Why is my inline style an error?
Because AMP disallows the style attribute outright. The runtime controls layout and needs to be able to reason about the page, so all author CSS goes in a single <style amp-custom> block in the head. This is one of the most common surprises when converting an existing page.
What is the CSS limit?
75,000 bytes for the amp-custom stylesheet — measured in bytes, not characters, so multi-byte content counts for more. It is the one AMP limit you cross gradually rather than all at once, which is why the tool shows it as a bar rather than a pass or fail.
Why does the charset position matter?
Because AMP requires <meta charset="utf-8"> to be the first child of head, not merely present. Putting a title or a comment above it is a genuine validation error, and it is invisible unless something checks the ordering rather than just the existence of the tag.
Is AMP still worth using?
Much less than it once was. Search no longer requires AMP for top-stories placement, and the format's main incentive has gone with it. If you have existing AMP pages this is useful for keeping them valid; if you are starting fresh, it is worth asking whether you need AMP at all rather than making a fast ordinary page.
How we compare
| Feature | Online Tool Store | The official validator | Browser devtools extension |
|---|---|---|---|
| Works on markup that is not published yet | ✓ | Paste mode only | ✗ |
| Nothing sent anywhere | ✓ | ✗ | Fetches the ruleset |
| Shows the CSS budget as a proportion | ✓ | Only when over | ✗ |
| Explains each rule in plain terms | ✓ | Terse codes | Terse codes |
| Cross-checks components against their scripts | ✓ | ✓ | ✓ |
| Authoritative pass or fail | ✗ | ✓ | ✓ |
| Every per-component attribute rule | ✗ | ✓ | ✓ |
Use this while writing, on markup that is not live yet and that you would rather not paste into someone else's service. Then use the official validator before you publish — it is the authority, and this never claims to be.