How to build frontmatter for mdx posts (astro / next.js)
- Step 1Load the MDX body — Paste the MDX (Markdown plus JSX) into the textarea, or upload it as a single
.md/.txtfile. The tool treats it as text and only touches the leading frontmatter block — your JSX is preserved. - Step 2Enter Title and Date — Type the title and an ISO date
2026-06-13. If your schema usespubDateinstead ofdate, note this tool emitsdate— you may need to rename the key by hand or adjust your schema. - Step 3Fill Slug and Description — Slug feeds your route/collection entry id; Description maps to your SEO/meta prop. Leave either blank to omit it.
- Step 4List Tags — Comma-separate tags, e.g.
astro, mdx, components. They become a YAML array your layout can iterate asfrontmatter.tags(Astro) or a prop (Next.js). - Step 5Set the Draft flag — Tick Draft for unpublished posts. The flag is always written; wire
draftinto your collection filter (Astro) or your route logic, since neither Astro nor Next.js hides drafts automatically. - Step 6Add schema-required keys, save as `.mdx` — After downloading, add any keys your schema requires that aren't in the six — commonly
image/ogImage,layout,author, or a renamedpubDate— then save with the.mdxextension in your content directory.
MDX schema fields: in the form vs. add-by-hand
Typical MDX frontmatter keys across Astro/Next.js/Remix, and whether this six-field form covers them. There is no ogImage, image, layout, or author control.
| Common MDX key | From the form? | Notes |
|---|---|---|
title | Yes | Title field |
description | Yes | Description field; maps to meta/SEO prop |
tags | Yes | Comma list → YAML array |
slug | Yes | Route / collection entry id |
date / pubDate | Emits date | Rename to pubDate by hand if your schema needs it |
draft | Yes (always written) | Wire into your own collection filter; not auto-hidden |
image / ogImage | No | Add by hand for social cards |
layout | No | Add by hand (Astro layout shorthand) if used |
author | No | Add by hand |
MDX loaders and the YAML block
How the major frameworks consume the --- block this tool emits. The block format is identical; the access pattern differs.
| Framework | Reads `---` YAML? | How you access it |
|---|---|---|
| Astro Content Collections | Yes | entry.data (validated by your zod schema) |
| Astro MDX pages | Yes | frontmatter prop / Astro.props.frontmatter |
Next.js (@next/mdx) | Yes | Parsed by gray-matter / loader, passed as props |
Next.js (next-mdx-remote) | Yes | data from serialize() |
| Remix (MDX route) | Yes | Exported attributes / loader data |
Cookbook
MDX-focused examples. The block is YAML the loader reads; JSX in the body is untouched. Comments flag schema keys you add by hand.
MDX post with JSX in the body
The tool only writes the leading YAML; the JSX component import and usage below it are preserved verbatim.
Paste (MDX body):
import Callout from '../components/Callout.astro'
# Getting Started
<Callout type="info">Read this first.</Callout>
Form: title=Getting Started, date=2026-06-13,
slug=getting-started, tags=astro, mdx
Output:
---
title: Getting Started
date: '2026-06-13'
slug: getting-started
tags:
- astro
- mdx
draft: false
---
import Callout from '../components/Callout.astro'
# Getting Started
<Callout type="info">Read this first.</Callout>Adding the keys Astro's schema requires
An Astro collection schema requires image and pubDate. The tool emits date and no image; you add both by hand to satisfy the zod schema.
Downloaded: --- title: My Post date: '2026-06-13' draft: false --- After manual edit for the schema: --- title: My Post pubDate: '2026-06-13' # renamed from `date` image: ./cover.png # added; not a form field draft: false ---
Description with a colon stays valid for the strict parser
MDX tooling uses a strict YAML parser; an unquoted colon fails it. The serializer quotes the value.
Form: description=MDX in Astro: a practical guide Output: --- description: 'MDX in Astro: a practical guide' draft: false ---
Tags consumed as a component prop
The YAML array maps cleanly into a Next.js or Astro component.
Output:
---
tags:
- react
- mdx
draft: false
---
Astro layout:
{frontmatter.tags.map((t) => <Tag key={t} name={t} />)}Replacing a foreign block on an imported MDX file
An MDX file imported from another stack carries a different block. The tool strips it and writes your fields; non-covered keys are dropped.
Paste: --- title: Imported ogImage: /old.png author: jane --- # Imported Form: title=Imported Post, date=2026-06-13, tags=mdx Output: --- title: Imported Post date: '2026-06-13' tags: - mdx draft: false --- # Imported # Note: `ogImage` and `author` were stripped — re-add them # if your schema requires them.
Edge cases and what actually happens
Astro build fails: required `image` (or other) field missing
Schema rejectAstro Content Collections validate every entry against your zod schema. If the schema marks image, pubDate, or author as required and you didn't add it by hand, the build throws a validation error. This tool only writes the six fields and does not read your schema — add required keys manually after running.
Schema expects `pubDate` but the tool emits `date`
Key mismatchMany Astro/Next.js MDX schemas use pubDate rather than date. The tool always emits the key date. Rename it to pubDate in the downloaded block, or align your schema to accept date.
No ogImage / image field for social cards
Not a fieldThere is no ogImage or image control in the six-field form. Open Graph images are essential for MDX blog social sharing, so add image: or ogImage: by hand to the downloaded block (and ensure the path resolves under your content directory).
Drafts still appear on the site
Not auto-hiddenNeither Astro nor Next.js hides draft: true content automatically. The tool writes the flag, but you must filter on it — e.g. in an Astro collection query (getCollection('blog', ({ data }) => !data.draft)) or your Next.js route logic. Without that filter the draft renders.
JSX accidentally placed in frontmatter
InvalidJSX and component imports belong in the MDX body, never inside the --- block — YAML cannot hold JSX. The form has no body-editing fields, so just keep your imports/JSX below the frontmatter in the input you paste; the tool preserves them as-is.
Output is YAML, not a JS/TS config export
By designSome setups define metadata as a JS/TS export (export const meta = {...}) instead of YAML frontmatter. This tool only produces a --- YAML block. If your MDX setup uses an export object, this tool's output won't fit — convert it by hand or use frontmatter mode.
i18n / translation metadata needed
Not a fieldThere is no language or translationKey field. Add i18n keys manually after running, or rely on your framework's directory-based i18n routing (Astro src/content/<lang>/, Next.js locale folders).
MDX file over the free 1 MB / 500k-char cap
Tier limitFree tier allows 1 MB / 500,000 characters per run. A normal MDX post is far smaller; this only bites on very large embedded content. Pro raises the cap to 10 MB / 5,000,000 characters.
Frequently asked questions
Does this support Astro Content Collections?
The YAML block it emits is read by Astro Content Collections via entry.data, so the format is compatible. But Astro validates each entry against your zod schema, and this tool does not read that schema. If your schema requires fields outside the six (commonly image, pubDate, or author), add them by hand to the downloaded block or the build will fail validation.
How do I add JSX components?
JSX and component imports live in the MDX body, not the frontmatter — YAML can't hold JSX. Keep your import lines and <Component /> usage below the --- block in the input you paste; the tool only writes the leading YAML and preserves the body, including all JSX, exactly.
Can I include an ogImage for social cards?
Not through the form — there is no ogImage or image field. Open Graph images matter for MDX blog sharing, so add image: or ogImage: manually to the downloaded block, pointing at a path your framework resolves (a co-located asset in Astro, or a public path in Next.js).
My schema uses `pubDate`, not `date` — what do I do?
The tool always emits the key date. After downloading, rename it to pubDate in the block, or change your schema to accept date. The tool has no option to rename the date key, since the field set is fixed.
Will drafts be hidden automatically?
No. The tool writes draft: true/false, but neither Astro nor Next.js hides drafts for you. Filter on the flag yourself — in Astro, exclude them in your getCollection query; in Next.js, skip them in your route/listing logic. Without a filter, draft: true posts still render.
Can I include i18n / translation metadata?
Not via the form — there is no language field. Add i18n keys (lang, translationKey) manually to the downloaded block, or use your framework's directory-based locale routing. The six fixed fields don't cover translation metadata.
Is the output YAML or a JS/TS export object?
Always YAML, delimited by ---. The tool never produces a JS/TS export const meta = {...} block or JSON. If your MDX setup reads metadata from a JS export instead of frontmatter, this tool's output won't drop in directly — use frontmatter mode in your loader, or convert by hand.
Does it work with Next.js MDX and Remix too?
Yes. @next/mdx and next-mdx-remote both read the --- YAML block (via gray-matter), and Remix's MDX route exposes it as attributes. The block format is identical across all three; only the access pattern differs by framework.
Will my existing MDX frontmatter be kept?
No. An existing leading --- or +++ block is stripped and rebuilt from the six form fields. Keys outside those six — image, author, layout, pubDate — are discarded. Copy them out before running and re-add them to the downloaded block.
Does the date auto-fill to today?
No. The Date field is blank until you type an ISO date like 2026-06-13. There is no auto-insert, and the value is written exactly as entered (single-quoted by the serializer).
Can I add an `author` field for the byline?
Not through the form — there is no author control. Add author: by hand to the downloaded block. If your MDX schema requires it, the Astro/Next build will reject the entry until the key is present, so add it before saving the .mdx file.
What other tools pair well for an MDX blog?
Add a contents list with md-toc-generator, rewrite image paths when co-locating assets with md-image-path-rewriter, validate links with md-link-validator, strip stray emoji with md-emoji-remover, and preview the rendered Markdown with md-to-html.
Privacy first
All Markdown processing runs locally in your browser using JavaScript. No file is ever uploaded to JAD Apps servers — only metadata counters are saved for signed-in dashboard stats.