Frontmatter is the small block of YAML that sits above a Markdown document and gives it machine-readable properties — a title, a date, tags, a status. Static site generators use it to build indexes, note tools use it to filter and sort, and pipelines use it to route files. Markdown Studio gives frontmatter a dedicated properties panel at the top of every document, so you fill in fields instead of hand-editing YAML.
What the properties panel does
Open any .md file in Markdown Studio and the panel sits above the content, before the first block. It reads whatever frontmatter the file carries and presents it as editable fields; when you edit, it writes the YAML back in valid form between the standard markers. Documents without frontmatter simply show an empty panel.
Typical properties in the wild:
| Property | Used for |
|---|---|
| title | Page titles and feed entries |
| date | Sorting and publishing order |
| tags | Grouping and filtering |
| status | Draft, review, published |
| author | Attribution in multi-writer collections |
Nothing about the list is fixed — the panel accepts custom keys, so whatever schema your blog, wiki or pipeline expects is just fields to fill in.
Edit properties step by step
- Open the document and click into the properties panel at the top.
- Fill the fields that matter: a title, the date, any status your workflow tracks.
- Add custom keys where your tooling expects them — categories, slugs, review dates.
- Save with Ctrl+S or let autosave write the file.
- Check the result in any text editor: the properties appear as YAML between the markers at the very top of the file.
Because the panel is a view over the YAML — not a separate database — the file keeps telling the whole truth. Any other tool that reads frontmatter reads exactly what you edited.
A frontmatter schema that survives a year
Schemas fail by ambition. The fields that still get filled in twelve months later are the ones with an obvious value and an obvious use:
- title — because filenames stop being enough around file forty.
- date — because sorting by modification time is not sorting by meaning.
- status — draft, review, published; the one field that makes a folder of notes queryably honest.
- tags — three at most, drawn from a vocabulary you actually maintain.
Add nothing else until a real need appears — an unused field trains you to skip the panel, and then the useful fields rot too. If the documents feed a static site generator, mirror whatever its templates expect; the panel writes any key you give it, so the schema is yours to define and yours to keep small.
Frontmatter and the tools around it
The properties panel earns its keep in three concrete loops:
- Static sites — Hugo, Jekyll, Astro and friends read the YAML directly; a folder of tagged, dated .md files becomes a blog or knowledge base with no database in sight.
- Search and scripts — one-line grep or ripgrep commands find every file with a given status or tag, which is the low-tech query language that still outlives every app.
- The AI panel — drafting with the title, date and tags in view keeps suggestions on-subject; a note marked status: draft gets bolder ghost text than one marked published.
The third loop is the newest and quietly the most useful: properties are how you tell tools what a document is, and the panel makes telling them cost three fields instead of a syntax lesson.
Why frontmatter matters
Plain Markdown has one weakness at scale: files are anonymous. Ten documents with no metadata are ten files in a folder; the same ten documents with title, date and tags properties are a queryable collection. That is the entire trick behind static site indexes, zettelkasten-style note systems and content pipelines — and it costs three fields per document.
The portability rule from getting started with Markdown Studio applies here too: the panel writes standard YAML, so Jekyll, Hugo, Astro, Obsidian and every frontmatter-aware tool consume the files without conversion.
Working with the rest of the document
Properties live above the content, and the two stay out of each other's way: the panel is the first thing in the document, the block editor takes over below it, and the boundary between YAML and prose is handled for you. When the document is ready to leave the editor, the AI panel can use the properties as context for drafting, and DOCX export maps the title property into the document's heading.
Troubleshooting a file that will not parse
Frontmatter is YAML, and YAML has opinions. If a static site generator or script complains about a file, the cause is almost always one of these:
- Unquoted values with special characters — a title containing a colon should be wrapped in quotes; the panel handles common cases, but hand-edited files drift.
- Indentation with tabs — YAML wants spaces; a tab pasted from elsewhere breaks the whole block.
- Duplicated keys — two title fields from a merge; the panel shows the file's real state, so scroll up and look.
- A missing marker line — the opening or closing fence got deleted in a text editor; the panel will show the properties as plain text instead of fields.
The fix in every case is to open the file in Markdown Studio, correct the fields in the panel, and save — the YAML is rewritten in valid form, and the downstream tool is satisfied.
What to explore next
- Getting started with Markdown Studio — where the panel sits in the whole flow.
- Slash commands — building the content below the properties.
- Export to DOCX — what happens to properties in the export.
- Rixoffice Markdown files — the format's role across the suite.