Codeharbor Markdown Preview

What it is for

A README, a changelog or a documentation page written in Markdown should look right and be well structured: one title, headings that go down one level at a time, links that lead somewhere and images that people using screen readers can understand. This tool renders Markdown to HTML and checks exactly those things:

• the rendered HTML (to copy or download);
• an outline of all headings with their levels and anchor ids;
• the word count and an estimated reading time;
• structure problems: skipped heading levels, more than one level-1 heading, links to anchors that don't exist, images without alt text.

It is the same renderer the Codeharbor app uses for its Markdown preview. Raw HTML inside the Markdown is shown as text, and only http, https, mailto and relative links become links — so the output is safe to put on a page.

Worked example

The first example is a small README for a tool called Lighthouse Kit with a title, an Install section, a numbered list, a task list, a table, a JavaScript code block and two links. The tool answers:

32 words (about 1 minute to read) with 2 headings and 1 structure problem.

The outline lists Lighthouse Kit (h1, id lighthouse-kit) and Install (h2, id install). The table keeps its right-aligned column (---:), the task list becomes disabled checkboxes and the code block is highlighted. The structure problem: The link “#example” points to a heading that does not exist. — there is no heading called Example, so the link would jump nowhere.

The second example shows three typical mistakes at once: a level-1 heading Guide, then a level-3 heading Details right below it, a second level-1 heading Second title, and an image diagram.png written with empty brackets, so it has no alt text.

The answer is 5 words (about 1 minute to read) with 3 headings and 3 structure problems: the heading “Details” skips a level (h1 → h3), there is more than one level-1 heading, and an image has no alt text.

How to read the result

• Outline — use it like a table of contents; the ids are the anchors you can link to with #id.
• Words / reading time — counted on the visible text, at about 230 words per minute, rounded up to whole minutes.
• Structure problems — each one is a whole sentence that says what to change.
• HTML — copy it into a page or download it as an .html fragment.

Tips and common mistakes

• The renderer follows CommonMark for the common cases and adds GitHub-style tables, task lists, strikethrough and autolinks in angle brackets (<https://…>). Footnotes, definition lists and math are not supported.
• Heading ids are lower case with hyphens; accents are dropped (Über uns → uber-uns). Two headings with the same text get -1, -2 suffixes.
• Write alt text that says what the image shows, not “image” or the file name.
• Code blocks are highlighted for JavaScript, TypeScript, HTML, CSS, JSON, Python, SQL, YAML and shell when the fence names the language ( `js ).

FAQ

Is the HTML safe to put on my website?

Raw HTML inside the Markdown is escaped, and only http, https, mailto and relative links are kept, so the output contains no scripts or event handlers. Style it with your own CSS.

Why is my link marked as a problem?

Links that start with # must match the id of a heading in the same text. Check the outline for the exact ids.

Does it support GitHub-flavoured Markdown?

Tables, task lists, strikethrough and autolinks in angle brackets, yes. Mentions, issue references, footnotes and emoji shortcodes are not converted.

How is the reading time worked out?

From the number of visible words at about 230 words per minute, rounded up to whole minutes, with at least one minute.