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.
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>old</del>. Autolinks work too. It is the standard Markdown defined by CommonMark plus the GFM extensions, so what you saw on GitHub is what you copy out.
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 runs through DOMPurify before it reaches the page, so even if a <script> or an onerror attribute is hiding in the Markdown, it never executes in the preview. 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?
The rule of thumb is simple. It comes down to whether you trust where the Markdown came from.
If you are converting your own README or docs, the copied source is fine to use as is. But if you convert Markdown that a user typed, like a comment or a post, and render it on the web, pasting that raw HTML straight in opens the door to XSS (cross-site scripting). Blocking <script> alone is not enough, since event attributes like onerror are vectors too. Always re-sanitize untrusted input on your server.
| Source of the Markdown | Use the copied source as is |
|---|---|
| Your own documents | Fine |
| User input (comments, etc.) | Re-sanitize on the server |
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.
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 runs every conversion in your browser, so the input is never transmitted and your drafts stay on your machine. Use the live preview to check the result, copy the source with the sanitize distinction in mind, and move on. 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.