How to final format pass before publishing
- Step 1Finish your edits first — Prettify last. Do your content edits, then run this pass so the final spacing is clean and nothing shifts afterward.
- Step 2Open the prettifier — Go to /markdown-tools/md-prettifier. It runs in your browser, so the unpublished draft stays on your machine.
- Step 3Paste or drop the near-final draft — Paste the source or drop one
.mdfile (free tier: 1 MB / 500,000 characters). - Step 4Set wrap width to match your target — Leave
No wrapif your CMS/renderer soft-wraps; pick80/100/120 colsif your publishing pipeline expects fixed-width source. - Step 5Run and spot-check — Click Run, then confirm headings are spaced, no lines end in stray spaces, and gaps are uniform. The output keeps your filename.
- Step 6Publish (and optionally lint) — Paste the result into your CMS or commit it. For a final rule check, follow with the linter before shipping.
Pre-publish issues this pass catches
Each is a small formatting flaw that's easy to miss in a near-final draft and the prettifier resolves deterministically.
| Pre-publish flaw | Risk if shipped | Prettifier fix |
|---|---|---|
| Heading flush against its paragraph | Some parsers/renderers mis-treat the heading or render it cramped | One blank line inserted before and after each ATX heading |
| Trailing whitespace on a list/prose line | Can break a list continuation or leave stray artifacts | Trimmed from every prose line (code fences excluded) |
| Three-or-more blank lines | Awkward gap in source-view or strict renderers | Collapsed to a single blank line |
| Leading blank lines at file top | Dead space before the title | Stripped from the body; frontmatter kept intact |
| Unwrapped long prose (target wants fixed width) | Source doesn't match pipeline expectations | Optional wrap at 80/100/120 cols |
| Your finished content | Accidental edit during cleanup | Untouched — content is preserved byte-for-byte |
Wrap width vs. publishing target
Choose based on how your CMS or static-site generator handles source line breaks.
| Choice | wrapWidth | Best when your target… | Note |
|---|---|---|---|
| No wrap (default) | 0 | Renders Markdown and soft-wraps prose itself (most CMS / GFM) | Keeps long lines; safest default |
| 80 cols | 80 | Expects classic 80-column source (some doc generators) | More, shorter lines |
| 100 cols | 100 | Wants moderate fixed-width source | Balanced |
| 120 cols | 120 | Prefers wide fixed-width source | Long lines may still soft-wrap visually |
Cookbook
Before/after source as it might look on a near-final draft — the pass tidies spacing only.
Heading spacing made unambiguous for the renderer
A heading with no blank line above it can render cramped or, in strict parsers, be misread. The final pass guarantees one blank line on each side.
Before: Thanks for reading. ## Related posts - Post one After: Thanks for reading. ## Related posts - Post one
Trailing space that would break a list continuation
A trailing space after a list item's paragraph can disrupt continuation in some parsers. Trimming it before publish avoids the surprise. (Trailing spaces shown as ·.)
Before: - Step one·· continued detail After: - Step one continued detail
Triple blank line tidied before shipping
Extra gaps from editing collapse to one blank line, so the published source is clean.
Before: Conclusion. ## Footnotes Text. After: Conclusion. ## Footnotes Text.
Wrap to 80 cols for a fixed-width pipeline
If your static-site generator expects 80-column source, set the dropdown and the prose wraps cleanly before commit.
Wrap width: 80 cols Before: This post walks through the entire deployment checklist we use for every release, end to end. After: This post walks through the entire deployment checklist we use for every release, end to end.
Frontmatter and code untouched on publish
A blog post's YAML frontmatter and any code samples are preserved exactly; only the prose spacing is tidied.
Before: --- title: Release v3 date: 2026-06-13 --- # Release v3 Highlights below. ```sh npm i app@3 ``` After: --- title: Release v3 date: 2026-06-13 --- # Release v3 Highlights below. ```sh npm i app@3 ```
Edge cases and what actually happens
Two-space hard breaks in the draft
RemovedThe final pass trims trailing whitespace, removing CommonMark two-space hard breaks — which changes how those lines render. Before publishing, replace them with a trailing backslash (\) or a blank line if you need the break.
Setext headings in an older post
By designOnly ATX (#) headings are spaced. A title underlined with ===/--- is treated as prose and not spaced. Convert to ATX before the final pass if you want consistent heading spacing.
Frontmatter on a CMS/static-site page
PreservedYAML/TOML frontmatter is detected, split off, and re-attached unchanged — so the publish pass won't churn the metadata your site generator reads.
Code samples with meaningful trailing whitespace
PreservedInside fences, lines pass through verbatim. A shell or diff example that relies on trailing spaces ships exactly as written.
GFM table in the post
Out of scopeTable rows are skipped by both the spacing and wrap passes, so a misaligned table isn't fixed here. Run table repair before publish if a table looks broken.
No trailing newline in the output
ExpectedThe output ends on the last content character. If your CMS or repo requires a final newline, add it after the pass or let your linter enforce MD047.
List indentation left as drafted
By designThe prettifier does not re-indent lists. If the draft has inconsistent nesting, fix it with the list fixer before publishing.
Draft exceeds the free-tier size cap
413 / blocked on freeFree is 1 MB / 500,000 characters per file. A long-form post with many images-as-data-URIs can hit the character cap first; upgrade to Pro (10 MB / 5,000,000) if needed.
Emphasis markers vary (_x_ vs *x*)
By designEmphasis markers are preserved exactly. To standardise them before publish, use the bold/italic cleaner.
Inline HTML embedded in the post
PreservedRaw HTML (embeds, <figure>, <details>) is treated as prose: trailing whitespace trimmed and blank-line rules applied around adjacent headings, but the markup itself is never altered.
Frequently asked questions
What does the final pass actually clean up?
It inserts one blank line before and after each ATX heading, trims trailing whitespace from prose lines, and collapses runs of three-or-more blank lines to one. Optionally it wraps prose at 80/100/120 cols.
Is it safe to run on a near-final draft?
Yes. It's content-safe — words, links, emphasis, lists, and fenced code blocks are byte-identical after a run. Only spacing changes, so it can't undo your final edits.
Should I prettify before or after editing?
After. Do your content edits first, then run the prettifier as the final spacing pass so nothing shifts before you publish.
Will it fix a broken table in my post?
No — table rows are skipped. Use table repair for tables before publishing.
Does it touch my frontmatter?
No. YAML/TOML frontmatter is split off and re-attached byte-for-byte, so your CMS or static-site metadata is preserved.
Should I wrap the source before publishing?
Only if your pipeline expects fixed-width source. Most CMS/GFM renderers soft-wrap prose themselves, in which case leave the dropdown on No wrap.
Will it remove my intentional line breaks?
Two-space hard breaks are removed by the whitespace trim. Use a trailing backslash (\) or a blank line for breaks that survive the pass.
Does it add a final newline?
No. The output ends on the last content character. If your repo or CMS requires a trailing newline, add it after the pass or rely on a linter rule (MD047).
Is the unpublished draft uploaded anywhere?
No. Processing is in-browser; the draft never reaches a server before you publish. Only an anonymous processed-file counter is recorded for signed-in stats, and it's optional.
How large a post can I process for free?
Up to 1 MB or 500,000 characters per file. Larger posts need Pro (10 MB / 5,000,000 chars) or higher. The character cap is separate from the byte cap.
Can I add this to my publish automation?
The web tool is interactive. For automation, the tool's GET endpoint returns its schema, and execution is runner-backed via @jadapps/runner, which runs the transform in-process locally so the draft never touches JAD servers.
What should I run after the prettifier before shipping?
For a final rule check, run the linter. If you're converting the post, use the relevant converter (for example, md-to-html) afterward.
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.