Markdown formatted string not handled correctly

LibreTranslate API
1

Hi,

we are using LibreTranslate 1.9.5 on a self-hosted instance.

Our app stores message bodies as Markdown. Since LibreTranslate supports text and html, but apparently not markdown, we currently send Markdown content as plain text with format=text.

We are seeing that LibreTranslate can modify Markdown image references even when the Markdown syntax itself remains intact.

Minimal reproducible example:

Request:

curl --fail-with-body -sS -X POST \
  "https://<our-instance>/translate" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode $'q=test message\n\ntest test\n\n![](news-records/f6430269-0ef4-4782-a1c8-646c43ff3924/2026-03-29/images/example.jpg)\n\ngood bye' \
  --data-urlencode 'source=en' \
  --data-urlencode 'target=el' \
  --data-urlencode 'format=text' \
  --data-urlencode 'api_key=<api-key>'

Response:

{
  "translatedText": "μήνυμα δοκιμής\n\nδοκιμή\n\n![](news-records/f6430269-ef4-4782-a1c8-646c43ff3924/2026-03-29/images/example.jpg)\n\nαντίο"
}

Problem:
The Markdown image syntax is still present, but the path inside it was changed.

Original path:
f6430269-0ef4-4782-a1c8-646c43ff3924

Translated path:
f6430269-ef4-4782-a1c8-646c43ff3924

So the Markdown remains syntactically valid, but the referenced file path is no longer identical, which breaks image rendering.

Questions:

1. Is this a known limitation when Markdown is sent with format=text?
2. Is converting Markdown to HTML and using format=html the recommended workaround?
3. Is there any safer way to preserve Markdown image/link references exactly during translation?

Thanks.
2

At present, you’ll need more sophisticated logic to handle markdown. Maybe you could convert markdown to HTML, translate it, then convert it back to markdown.

Or help us add support in LibreTranslate to do this directly?

1 Like
3

Thanks for the clarification.
I managed to convert it to html and translate it. Instead of converting it back to Markdown, I’m just displaying the HTML translations.
Would be cool to support this project, but unfortunately I can’t because of too less knowledge (ok, this can be changed) and too much tasks… (I know, sounds like a standard excuse)