Paste the front matter from many Markdown posts at once and check them against each other — not just one file at a time. Catches missing fields, the same field living under two different names, mixed date formats, type drift, and duplicate slugs across your whole content folder.
Paste each post starting with its --- front matter fence. Separate posts with a line containing just -----. Optionally start a block with ### filename.md to label it in the results. The Markdown body below the front matter is ignored, so you can paste whole files or just the fenced block.
Set this to whatever your site's build actually needs — Astro's schema fields, Hugo's required params, or just leave the defaults.
A YAML validator tells you whether one block of front matter parses. That's a real check, but it's not the one that breaks builds. The failures that actually cost you an afternoon are relative: the post where someone wrote publishDate instead of date, the three posts that use 01/12/2026 while everything else uses 2026-01-12, the field that's a list in forty files and a bare string in one. Every one of those files is individually valid YAML. The problem only exists in comparison — which is why a single-file checker can't see it, and why this tool takes the whole batch at once.
Per file: whether the fence is present, opens at the very first line, and closes; whether the YAML parses; whether your required fields exist and are non-empty; empty values on any other field; and duplicate keys — which parsers silently resolve by keeping the last value, so the earlier one disappears without any error.
Across the batch: fields that appear in some posts but not others; two field names that are never used together, which almost always means they're the same field under two spellings; fields whose value type changes between files (a list in most, a string in one); date fields written in more than one format; and duplicate title, slug, permalink, or url values, which usually means two posts will fight over the same output path.
This is the one worth understanding, because it's the one that silently drops content. When a post uses publishDate and your template reads date, nothing errors — the template just renders an empty date, or the post sorts to the bottom, or it falls out of a filtered collection entirely. The build passes. The post looks fine in your editor. You find it weeks later when someone mentions the archive page is missing something.
Naming drift is flagged only when two similar field names never appear in the same file. That distinction matters: title and subtitle are genuinely different fields and normally coexist, so they're not flagged, while date and publishDate splitting cleanly across two groups of files is the signature of the same field written two ways.
No. The page loads the open-source js-yaml parser from a CDN once when it opens, and after that everything runs in your browser — parsing, comparison, and results. Your content never leaves the device, which you can confirm in your browser's Network tab.
Not currently — TOML blocks are detected and reported as unparsed rather than silently skipped, so you'll know they weren't checked. Hugo accepts both, but YAML is by far the more common choice across Jekyll, Astro, Eleventy, Next.js, and Hugo itself.
Both are read as the same date here as long as the format matches, so this tool won't flag it on its own. It's still worth being deliberate about: in YAML, an unquoted 2026-01-05 can be interpreted as a date value while "2026-01-05" is always a string, and generators differ in how they handle each. If your dates render inconsistently despite looking identical, quoting is a good first thing to check.
No — there's no server-side fetching here, so it only sees what you paste. For a folder of fifty posts, the fastest route is concatenating the front matter blocks with a shell one-liner and pasting the result. If you'd rather have it run automatically on every commit, a CLI validator wired into CI is the better tool for that job; this one is for the moment you're actually looking at the problem.
Then the mismatch is with your generator's schema rather than with YAML itself — Astro validates against a Zod schema, and a field that parses fine can still be the wrong type or fail a constraint. Set the required-fields box to match your schema's required keys and the type-drift check will usually surface the offender. See the common front matter failures for the specific patterns that cause silent breakage.