Markdown to Literotica format converter

[TheLobster]

I looked into the em dash. As far as I know, if the webpage specifies to the browser it's using UTF-8 character encoding, then Unicode characters like em dashes are displayed just fine as-is. Looking at Literotica's story pages, I see <meta charset="utf-8"> in the source code, so I think em dashes should work fine without using HTML entity &mdash;

To clarify, you absolutely correct about this, but the handling of literal em-dashes is just another undocumented part of Literotica's text processing algorithm that diligent authors here have discovered. If you want them preserved, &mdash; refs are required; I mostly just don't care but I know some people do.

Thanks for your work on this tool!

 

[TheLobster]

Please test and report any issues.

So, it seems that multiline formatting is now just ignored:



The expected output here, to cooperate with Lit's paragraph breaking, is this:

<strong>test multiline</strong>

<strong>another line</strong>

<strong>more lines</strong>

 

[IWroteThis]

I see, thanks for the info.

Updated tool:
Replace unicode characters Em Dash "—" and Ellipsis "…" with the HTML entities "&mdash;" and "&hellip;"

Well, I learned something today. I didn't realize that it was replacing all of my ellipses with period triplets. I'll have to add that to my HTML tagging step.

 

[HelenL]

I created a tool to convert text in Markdown syntax to the Literotica plaintext format with a few allowed HTML tags (the format required to publish stories).

https://markdown-to-literotica.pages.dev/
(updated: 2025-10-13)

Hope it's helpful. Let me know if you encounter bugs or have suggestions.

Tip:
One way to output Markdown for rich formatted text is to use Google Docs. Enable Markdown, and then right-click and select "Copy as Markdown". Instructions here.

Notes:

• Tool supports HTML tags documented in the official FAQ and FrancesScott's Guide.
• Gracefully handles line breaks, paragraphs, and tag closing per line based on feedback here.
• Replace unicode characters Em Dash "—" and Ellipsis "…" with the HTML entities "&mdash;" and "&hellip;"
• See the Help Modal for supported Markdown syntax conversions.
• All data is processed locally in your browser. No data is transmitted or stored remotely. VirusTotal scan

I was wondering about doing this myself. I'm glad I don't have to! Is it built on a particular Markdown parser? If I switch to Markdown (which is my goal) I still need to convert Markdown to my own site's source format, so I could use recommendations on parsing.

Oh, and thank you for this!

 

[sleepybowl]

So, it seems that multiline formatting is now just ignored:

View attachment 2570979

The expected output here, to cooperate with Lit's paragraph breaking, is this:

<strong>test multiline</strong>

<strong>another line</strong>

<strong>more lines</strong>

@TheLobster Thx for that feedback. I did look into the issue you raised. Apparently there's a convention in Markdown where the formatting delimiters (tags?) cannot span multiple lines when there are blank lines between them. It must either be on the same line, or the very next line (one single linebreak). So I followed that convention. Google Docs seems to be even more conservative: it wraps every line in delimiters and never spans lines.

Try it in these Markdown editors:
https://dillinger.io/
https://markdownlivepreview.com/

I'm unsure what the true official expectation is in Markdown. It seems ambiguous and Markdown editors just follow some convention. It's probably not a good idea to rely on consistent treatment of Markdown across lines; best to put the delimiters on the same line.

More discussion here:
https://forum.obsidian.md/t/formatting-like-bold-italics-etc-across-multiple-paragraphs/30229

I can’t find any authorative source describing whether or not multiple lines wrapped in emphasis is valid markdown or not, but most tools seem to treat it as invalid.

Just curious, are you using a tool that's outputting Markdown with multiple lines wrapped in one set of delimitters?

P.S.
For clarity, I followed this convention:

*Line1
Line2*

is converted to:

<em>Line1<br/>Line2</em>

Does that render as expected on Literotica?

*Line1

Line3*

is not treated as valid Markdown

In Google Docs, this:

Line1
Line2

Line4

is copied as this Markdown:

*Line1*
*Line2*

*Line4*

 

[sleepybowl]

I was wondering about doing this myself. I'm glad I don't have to! Is it built on a particular Markdown parser? If I switch to Markdown (which is my goal) I still need to convert Markdown to my own site's source format, so I could use recommendations on parsing.

Oh, and thank you for this!

I did not use any particular parser. This was vibe coded with Google Gemini 2.5 Pro.

 

[onehitwanda]

Sigh.

 

[joy_of_cooking]

This was vibe coded with Google Gemini 2.5 Pro.

Uhhh just to confirm you had an llm barf out a whole new markdown parser?

 

[onehitwanda]

Uhhh just to confirm you had an llm barf out a whole new markdown parser?

which uses java script, inline in the page, with its parsing done via regular expressions.

Time to sharpen ol' stabby.

 

[SugarStorm]

Time to sharpen ol' stabby.

Play nice. No ritual sacrifices on a Tuesday.

 

[sleepybowl]

Uhhh just to confirm you had an llm barf out a whole new markdown parser?

Yar. Initial goal seemed really simple: just convert bold and italics mainly. Scope creeped a bit, but the tool seems to meet the requirements.

 

[onehitwanda]

Play nice. No ritual sacrifices on a Tuesday.

 

[TheLobster]

its parsing done via regular expressions.

What could possibly go wrong…

 

[Five_Inch_Heels]

I did not use any particular parser. This was vibe coded with Google Gemini 2.5 Pro.

Which means any story processed with it will be rejected here.

Like I said way back folks ...


odd.

 

[sleepybowl]

Which means any story processed with it will be rejected here.

Like I said way back folks ...


odd.

I don't understand what this means. This tool does not change your prose. It just converts Markdown syntax to HTML tags supported by Literotica.

 

[sleepybowl]

What could possibly go wrong…

I'm not an expert. For what it's worth, I came across this: https://stackoverflow.com/questions...of-using-a-simple-regex-based-markdown-parser

That said, you can use a "simple regex-based" method to build a Markdown parser. In fact, this is exactly what the reference implementation uses (in Perl). It runs a series of regular expressions which replace the Markdown syntax with HTML syntax on the existing document.

Anyway, not trying to fight. I built the tool for my own use, thought it might be useful to others. If you find any parsing bugs, I'd love to know.

 

[SugarStorm]

Anyway, not trying to fight.

You’ll find that Author’s Hangout isn’t just home to some excellent authors, quite a few are very technically adept too.

And then there are people like onehitwanda and TheLobster, who can practically read the Matrix. No one’s looking for a fight; they’re just very, very passionate about their 1s and 0s.

I tried the tool but it's not for me I want to be in full control, especially since my stories are in the 30k word range.

That said, I genuinely love that someone’s out there trying to make submission a smoother, more simplified process. The tricky part is that very little is officially supported (which doesn't stop the more creative authors out there), and we're working with duct tape and hope when publishing our stories. If your tool does more than what's officially supported, I think that should be clearly labeled.

In terms of constructive feedback:

1. I think having a preview button on the markdown input would help.
2. When I start to scroll, the two sides don't stay aligned.
3. What I think is maybe a parsing issue, I wrote something like:
   Yada yada yada
   - S
   
   It converts the -S into:
   <ul>
   <li>S</i></li>
   </ul>
   
   Which messes up the formatting entirely. Had I sent that into a story of mine I'd have borrowed onehitwanda's pointy thing and stabbed myself.

 

[sleepybowl]

I think having a preview button on the markdown input would help.

I'll look into that. Maybe the preview should apply to both the left and right text fields. Currently the preview only applies to the right side.

When I start to scroll, the two sides don't stay aligned.

Are the scroll bars not moving together? Or do you mean the content shown on the two sides diverge if there's a lot of code causing the lines to not match up? On my end, the scroll bars do seem synced for me, but I see the problem if there's a ton of code, then the texts don't exactly line up. I'm not sure how to solve that...

Bigger culprit might be collapsing single linebreaks into a single line with <br/>, which shortens the output on the right if there are a lot of single linebreaks on the left.

If that is the issue, maybe the scroll syncing should be removed. Could also make it a toggle...

Yada yada yada
- S

It converts the -S into:
<ul>
<li>S</i></li>
</ul>

When I first read this, I thought you're right, maybe the unordered list and ordered list format should only trigger when there're at least two lines with the "-" or "1. 2." delimiter.

But to my surprise, the official Markdown syntax seems to treat a single list item as a list. Try pasting the above into:
https://dillinger.io/
https://markdownlivepreview.com/

I'm not sure what the best thing to do is.

A)
Be a purist and stick to the current behavior since that's how Markdown works. You can escape the "-" character with a backslash "\" if you don't want to treat it as formatting.

Yada yada yada
\- S

Google Docs does exactly this when you copy as Markdown.

B)
Change the logic to only recognize unordered and ordered lists when there are at least two list items. This actually makes more sense to me; why would anyone want a list of one item? But it's deviating from official Markdown syntax.

I'm lazy, so I'll just stick with A), the official Markdown behavior.