Markdown Front Matter Parser

Parse the front matter at the top of Markdown files used by Hugo, Jekyll and Next.js, separating fields from body text and merging them back into a complete document after form editing. Uses a simplified YAML parser, not a full specification implementation.

FreeOnline Tool
Loading…

How to Use

  1. Paste a complete Markdown document whose front matter is wrapped in --- at the very top, then click "Parse"
  2. The front matter fields appear as an editable form (one field per row) and the Markdown body is separated into the text box on the right. If the input uses syntax the simplified parser does not support, such as deeply nested objects, the "Parse notes" area lists exactly which line and which content was skipped
  3. Edit any field's key or value directly in the form; array fields take multiple values separated by commas. Click "+ Add field" to add a new field, or "Delete" on a row to remove one
  4. Edit the body simply by changing the body text box
  5. Click "Merge into complete Markdown" to recombine the current fields and body into a full Markdown document with --- front matter, shown at the bottom and copyable with one click
  6. Click "Load sample front matter document" to fill in an example containing string, date, boolean, number and array fields

Features

  • Automatically detects and separates the --- wrapped front matter at the top of a Markdown file from the remaining body content
  • The simplified YAML parser supports strings, numbers, booleans, date-formatted strings (kept verbatim as strings with no date math), inline arrays such as tags: [a, b, c], and multi-line - item list arrays
  • Works in reverse too: the parsed fields render as a form where you can edit field names and values (including adding and deleting fields) as well as the body, then merge everything back into a complete Markdown document with front matter
  • When it encounters content the simplified parser does not support (deeply nested objects, nested arrays, YAML anchors and references with & and *), it neither crashes nor invents data — it produces a note with the exact line number and skips that content
  • Important limitation: this is a simplified YAML parser, not a full YAML specification implementation. It covers only the front matter styles most commonly used by static site generators such as Hugo, Jekyll and Next.js MDX; use a dedicated YAML tool for complex YAML documents

Use Cases

Checking static blog posts in bulk
Quickly see whether a Hugo or Jekyll post's front matter fields such as title, date and tags are complete and correctly formatted.
Migrating Next.js MDX content
When moving content between static site generators, use the form to adjust front matter field names and values, then merge and export the new document.
Editing article metadata quickly
Change a post's publish status, tags or category directly in the form without hand-aligning YAML indentation and syntax.
Teaching content conventions
Demonstrate to a team where front matter YAML syntax ends, helping newcomers understand why certain complex constructs cause trouble in static site generators.

FAQ

Does the tool support the full YAML syntax?
No. It is a simplified YAML parser covering only the styles common in front matter: top-level key: value pairs (strings, numbers, booleans, date strings), inline arrays and multi-line lists. Deeply nested objects, nested arrays and YAML anchors and references (& and *) are not supported; when they appear the tool emits a note and skips them instead of fabricating a parse result.
Are date fields converted into Date objects?
No. Date-formatted strings such as 2024-01-01 are kept verbatim as strings with no date math and no time zone conversion, so a simplified parser never makes inaccurate assumptions about dates.
A parse note says a line was skipped — did I lose data?
That field will indeed be missing from the parsed result (or the array will be empty), but your original input text is untouched. The note tells you the exact line number and the unsupported content so you can inspect the original document yourself.
Will the merged document match my original formatting exactly?
Not exactly. Merging regenerates the YAML text by fixed rules — always using inline array syntax, adding double quotes where necessary — so comments and layout details beyond field order are not preserved. The keys and values themselves are carried over correctly.