TL;DR - If the message already exists in Markdown, do not paste raw
Markdown into Gmail or Outlook and then repair the formatting by hand. Start
with conservative rich email HTML, review the result after paste, and keep a
plain-text fallback ready. Use depapel for the
formatting step. Use PDF or DOCX
instead when the job is really an attachment or review document, not an email
body.
Some Markdown should become a document.
Some Markdown should become an email.
That sounds obvious, but a lot of real workflows blur the line. A status update,
client summary, launch note, or handoff already exists in Markdown because it
came from notes, docs, a README, or an AI draft. Then someone says: "send this
by email."
That is where the friction starts.
Raw Markdown is still easy to edit, but it is not what most people want to read
inside Gmail or Outlook. Headings, bullets, links, and code already exist in
the source, yet the inbox version can still end up looking sloppy if the paste
path is wrong.
The decision that matters first
Before formatting anything, answer this:
Should this stay in the email body, or should it become an attachment?
Keep it in the email body when:
- the message should be read and answered inline,
- the content is short enough to scan in the inbox,
- the structure matters, but page layout does not,
- or the next step is reply/forward rather than document review.
Turn it into PDF or DOCX when:
- the content is long enough to feel like a document,
- tables or layout are important,
- the next step is formal review or markup,
- or you need a fixed artifact rather than an email thread.
That split is more useful than arguing about whether Gmail or Outlook
"supports Markdown." The inbox job is different from the document job.
The practical workflow for email
If the answer is "this should be an email body," use this order:
- Keep the source in Markdown.
- Convert the Markdown into conservative rich email HTML.
- Paste it into Gmail rich text mode or Outlook HTML compose.
- Review the result before sending, especially spacing, lists, links, images,
and tables.
- Fall back to plain text if the compose surface or recipient path needs the
safer version.
That is the rule worth remembering:
rich HTML first, plain text when needed
Why raw Markdown paste breaks down
The naive path looks like this:
- Draft in Markdown.
- Paste raw Markdown into Gmail or Outlook.
- Notice that it looks wrong.
- Repair it manually.
That creates avoidable cleanup work.
Common problems:
- headings lose their visual hierarchy,
- bullet spacing gets messy,
- inline code and fenced code blocks become noisy,
- raw markers like
`code` or **bold** stay visible,
- tables do not survive gracefully,
- and images or richer HTML need review after paste.
This is the important mental model:
Markdown is a strong authoring format, but email clients are conservative
compose surfaces.
The goal is not to make Gmail or Outlook behave like a full Markdown renderer.
The goal is to carry the structure across cleanly enough that the message still
reads well.
What Gmail and Outlook actually support
On desktop, Gmail gives you a rich-text compose surface and a plain-text mode.
That means the practical question is not whether Gmail understands Markdown
directly. The practical question is whether your pasted result still looks
clean after Gmail applies its own compose rules.
Outlook's official guidance is similarly explicit:
- HTML is the format to use when you want lists, formatting, or pictures inside
the message.
- Plain text is the safer lowest-common-denominator path.
- Recipients can still see format conversion depending on their email program.
Microsoft documents that in its
Outlook message format support article.
That is why a Markdown-to-email workflow should produce both:
- a conservative rich HTML version,
- and a plain-text fallback from the same source.
A concrete Markdown source example
Markdown source:
# Friday launch update
We shipped the docs refresh and closed the onboarding fixes.
## What changed
- Signup now fits on one screen
- Error messages show inline
- The mobile CTA no longer jumps when the keyboard opens
## One command worth keeping visible
```bash
pnpm build
```
That source already has the useful signals:
- a subject candidate,
- a short intro,
- a scannable list,
- and one command that should stay visually distinct.
The email version should preserve those signals. It should not force you to
rebuild the whole thing inside the composer.
What a good Markdown-to-email conversion should keep
If the source is Markdown, the useful conversion is structural first.
It should preserve:
- headings as readable section titles,
- paragraphs with clean spacing,
- bullets and numbering,
- links that still work after paste,
- inline code and code blocks in a readable form,
- and a plain-text fallback when the rich version is not the right send path.
It should also be honest about what needs review:
- images can behave differently across clients,
- tables are more fragile than normal paragraphs and lists,
- and unsupported HTML should be simplified instead of passed through blindly.
Where depapel fits
depapel is a good fit for this exact step:
- paste Markdown into the editor,
- switch to the Email preview,
- copy the rich email HTML,
- or copy the plain-text fallback when needed.
The product role is intentionally narrow.
depapel does not send through Gmail or Outlook for you.
It does not pretend every email client will render every structure the same
way.
It gives you a conservative email-ready body from the same Markdown source, plus
a plain-text fallback when the safer route is the better one.
When plain text is the better answer
Rich HTML should be the first attempt, not the only attempt.
Use plain text when:
- the recipient path is unpredictable,
- the message must survive aggressive format stripping,
- the client or reply chain keeps downgrading the body,
- or the content is mostly short sections and bullets anyway.
Plain text is not a failure state. It is the lowest-risk delivery format.
The mistake is assuming you must choose plain text from the start when a clean
HTML paste would work fine. The opposite mistake is assuming HTML will survive
perfectly everywhere without a final check.
Honest limitations
This workflow still has limits.
- depapel formats the email body, but it does not send the message.
- Tables and images should be reviewed after paste in both Gmail and Outlook.
- The plain-text fallback is safer, but naturally loses rich structure.
- If the content is really a document, PDF or
DOCX is often the better output.
That is fine.
The value is not turning email into a publishing engine.
The value is getting from Markdown source to a readable inbox message without
doing manual cleanup twice.
Final rule to remember
If the source already exists in Markdown and the output should live in the inbox:
- keep the source in Markdown,
- try conservative rich HTML first,
- review the paste,
- and use plain text when the safer send path matters more than formatting.
That is the practical Markdown-to-email workflow for Gmail and Outlook.
References
Please enable JavaScript to use depapel.