Image correction — October 13, 2026: We removed the illustrated card set from this guide. Its “safe to preview and share” and “no tracking” wording overstated what this converter verifies, and its “Source: raw” illustration showed Markdown rather than the copied HTML. The examples below describe the actual output; the preview is not a publishing approval.
You wrote a clean README in Markdown, and now a CMS or an email needs it as HTML. Pasting it into a converter feels like the whole job, until the table falls apart, the lines run together, or someone converts a stranger’s Markdown and ships it straight into a page that then runs a script. Here is what actually matters when you convert.
Output correction — October 14, 2026: The earlier example wrongly changed the word “strikethrough” to “old.” Conversion keeps the text between the markers; it does not rewrite that word. The repeatable check below now shows the actual source.
How Markdown turns into HTML
The basics are familiar: # becomes a heading, * becomes emphasis. The tricky parts are extensions like tables and strikethrough.
The PiPi Worlds Markdown converter follows GitHub-flavored Markdown (GFM). A table expands into <table>, <thead>, and <td>, and ~~strikethrough~~ becomes <del>strikethrough</del>. Autolinks work too. GFM syntax support does not promise GitHub’s styling. The destination’s CSS, allowed tags, and email rendering rules can change the result.
The preview is sanitized; the copied source is raw
This is the distinction that matters most. What you see in the preview and what the copy button hands you are not the same thing.
The preview uses a separate formatting conversion: images become alt text, links become non-navigating text, and raw HTML is omitted. DOMPurify then processes that limited result with an allowlist. The copyable HTML source, by contrast, is the raw conversion. Convert Hi <img src=x onerror="alert(1)"> <script>alert(2)</script> and the source keeps that onerror and <script> intact. Not knowing this difference is where people get burned.
So where do you sanitize again?
Authorship alone is not a safety check. Even your own README can contain copied HTML or remote image URLs. Check what your destination permits, not just who wrote the document.
| Intended use | Check before publishing |
|---|---|
| Showing HTML as a code example | Use the destination’s code-block or escaping feature so tags stay text rather than being interpreted as HTML. |
| Rendering a page from HTML | Apply the destination’s allowed-tag, attribute, and URL policy. Do not use this preview as approval of user-submitted HTML. |
| Passing sanitized HTML through another processor | Check what that processor changes. DOMPurify warns that later modifications can undermine sanitization. |
Try [Read the notes](https://example.com/notes) in the converter. The preview shows the words without navigation; the HTML source still contains an anchor with an href. A working link in your CMS is therefore not a preview bug: the two outputs intentionally differ. This example checks conversion, not whether a destination URL or publication is safe.
Compare one input with both outputs
Paste this non-sensitive sample into the converter:
[Read the notes](https://example.com/notes)
The preview displays Read the notes as text, not a working link. The copyable HTML is:
<p><a href="https://example.com/notes">Read the notes</a></p>
That is HTML source, not the original Markdown. If you publish it as HTML, the destination may make the link clickable. Inspect that destination before publishing; this example does not certify it.
Use a private draft to check tables, line breaks, link destinations, and image sources before release. This is a publication checklist, not a security audit of your CMS or email service.
Why a single newline keeps the same line
It is small, but it trips people up constantly. You press Enter once in the Markdown and the HTML does not break the line.
Standard Markdown treats a single newline as a soft wrap. Split line 1 and line 2 with one Enter and they stay inside the same <p> paragraph. To truly separate paragraphs, leave a blank line between them. To force a break inside one paragraph, end the line with two spaces. When the spacing in an email or a CMS comes out wrong, this rule is usually why.
Check three formatting rules in one small example
Paste the following invented text into the English converter, then select HTML source. The end of line 3 contains two spaces before its newline. If your editor trims trailing whitespace, add those two spaces again; do not paste the words “two spaces.”
~~strikethrough~~
line 1
line 2
line 3
line 4
The source is:
<p><del>strikethrough</del></p>
<p>line 1
line 2</p>
<p>line 3<br>line 4</p>
Compare the tags, not just the apparent spacing: <del> preserves the word, the single newline between lines 1 and 2 stays inside one paragraph without a <br>, and the two trailing spaces after line 3 produce a <br>. Switch to Preview to see the formatting difference. This checks conversion in this tool; a CMS or email client can style those tags differently.
Example check — October 14, 2026: We entered this non-sensitive sample in the live English converter and compared its source view with the conversion function. This does not test your publishing destination or certify arbitrary HTML as safe.
Where are you running that conversion?
The last point is about where the conversion happens. When you turn a draft, a meeting note, or an unreleased spec into HTML, a tool that sends that text somewhere routes your pre-publication content through an outside server.
The PiPi Worlds Markdown converter processes the input in your browser and does not send the text to a conversion endpoint. That does not control browser extensions or the service where you later paste copied HTML. Do not test with real credentials or sensitive documents; use the live preview and keep the sanitized-preview versus raw-source distinction in mind when copying. If a base64 blob shows up inside the HTML, the Base64 tool handles it, and if a chunk of JSON is in there, the JSON formatter does.