Skip to content
Markdown Viewer

MDX Validator

Lint MDX for unclosed tags, missing imports, and brace errors

A fast pre-flight check for the three issues that most often break MDX builds. Designed for Next.js, Astro, Docusaurus, and Nextra workflows. Runs entirely in your browser — no Node, no install.

Frontmatter editorGFM checklistTypography cleaner
3 error(s)8 warning(s)

  • L11

    Component <Card> is used but not imported.

  • L13

    Component <Card> is used but not imported.

  • L15

    Component <Tabs> is used but not imported.

  • L16

    Component <Tab> is used but not imported.

  • L16

    Component <Tab> is used but not imported.

  • L17

    Component <Tab> is used but not imported.

  • L19

    Component <Tabs> is used but not imported.

  • L19

    Closing </Tabs> does not match open <Tab> from line 17.

  • L21

    Unbalanced JSX expression braces on this line.

  • L15

    Tag <Tabs> opened but never closed.

  • L17

    Tag <Tab> opened but never closed.

Heuristic checks only — finds unclosed JSX tags, unbalanced expression braces, and components used without an import. For full MDX compilation (transform rules, prop type checking), use your framework's build pipeline.

How to use the MDX validator

  1. Paste MDX or open a .mdx file with the picker.
  2. Read the issue list — each item shows the line number and a short explanation.
  3. Fix the issues in your editor and re-paste. The validator updates as you type.

What gets checked

CheckSeverityWhy
Unclosed JSX tagerrorBuild will fail; rendering is impossible.
Closing tag doesn't match opening tagerrorCommon after copy-paste; build fails.
Component used but not importedwarningRenders as plain text or throws at runtime.
Unbalanced JSX expression braceswarningCuts off interpolation; may swallow content.

Why MDX errors are painful

MDX errors usually surface at build time, sometimes only when a particular page is requested in production. The feedback loop is slow:

  1. You edit MDX.
  2. You git push.
  3. CI runs.
  4. Five minutes later, the build fails.
  5. You read a cryptic stack trace, find your unclosed <Card>, push again.

A fast pre-flight check catches the obvious cases in seconds.

Common MDX gotchas

  • Smart quotes inside JSX attribute values break parsing. Run the Typography Cleaner before validating.
  • Self-closing components need the trailing slash: <Image />, not <Image>.
  • Expressions in headings require special syntax — # {title} doesn't always work as expected; check your framework's MDX guide.
  • Imports must come before the first JSX block — putting them later silently breaks scoping.

Companion tools

Privacy & data

The validator runs inside your browser. We don't upload, log, or store the MDX you paste.

Frequently asked questions

What is MDX?
MDX is Markdown extended with embedded JSX. It lets you import React components and use them inline alongside Markdown prose. Used by Next.js (with @next/mdx), Astro, Docusaurus, Nextra, and many other frameworks.
What does this validator catch?
Three high-signal classes of bugs: (1) unclosed JSX tags — `<Tabs>` with no `</Tabs>`; (2) unbalanced curly braces in expressions — `{2 + 2`; (3) components used but not imported — `<Card>` referenced without a matching `import`. These are the three most common build-time MDX errors.
Will it find every MDX issue?
No — full MDX validation requires running the actual compiler. This validator is a fast pre-flight heuristic check that catches the bugs people hit most often. Use it before pushing; let your CI build pipeline do the final verification.
Does it understand component naming rules?
Yes — JSX treats names starting with a capital letter as components, lowercase names as HTML elements. The validator flags capitalized names that aren't imported (`<Tabs>`) but not lowercase tags (`<div>`).
What about HTML inside MDX?
Lowercase HTML tags are passed through. The validator still verifies they close properly to avoid invalid nesting.
Is my MDX uploaded?
No. The validator runs entirely in your browser.