You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add a configurable Markdown link serialization policy #3035
The Markdown exporter does not provide a public option to control how links are serialized.
When a URL-only link is created in BlockNote, blocksToMarkdownLossy may serialize it as a bare URL:
https://example.com
This is valid in GFM, but it loses the explicit distinction between ordinary text and a Markdown link. It also makes it difficult for applications to enforce a consistent Markdown export policy.
What did you expect to happen?
Applications should be able to choose whether links are serialized as:
https://example.com
or explicitly as:
[https://example.com](https://example.com)
For links with a separate label, the explicit format should remain:
[Documentation](https://example.com)
The default behavior should remain unchanged for backward compatibility.
Steps to reproduce
Create a BlockNote editor.
Insert a link where the displayed text is the same as the URL.
Export the document with blocksToMarkdownLossy.
Observe that the result may contain a bare URL instead of explicit Markdown link syntax.
Links with different labels continue to emit [label](url).
The option could be exposed through the lower-level Markdown exporter API as well.
Additional context
We initially implemented an application-level HTML-to-Markdown serializer only to change this link behavior. However, that requires duplicating BlockNote’s complete Markdown serialization logic and creates compatibility and maintenance risks when BlockNote changes its exporter.
A public link serialization option or hook would allow applications to customize this behavior without forking the whole serializer.
Contribution
I’d be interested in contributing a fix for this issue.
Hi @gitfromwildan, I understand your concern here, but, markdown is a lossy format, so I would prefer that in the case that a link is just it's href as text content, that we output just the bare link.
I'm not willing to open this up for configuration, because the method is explicitly lossy and to add one option invites another option and then we end up with hundreds of options for markdown.
What matters here more than anything is round-tripping which my PR will address, I hope this is enough of a solution for you.
Thanks for taking the time to address this and for implementing the round-trip solution. I really appreciate the thoughtful approach and the work you put into the PR. This looks like a good solution to the issue I raised. Thank you! 🙏
Activity
nperez0111 commentedon Sep 23, 2026
Hi @gitfromwildan, I understand your concern here, but, markdown is a lossy format, so I would prefer that in the case that a link is just it's href as text content, that we output just the bare link.
I'm not willing to open this up for configuration, because the method is explicitly lossy and to add one option invites another option and then we end up with hundreds of options for markdown.
What matters here more than anything is round-tripping which my PR will address, I hope this is enough of a solution for you.
gitfromwildan commentedon Sep 23, 2026
Thanks for taking the time to address this and for implementing the round-trip solution. I really appreciate the thoughtful approach and the work you put into the PR. This looks like a good solution to the issue I raised. Thank you! 🙏
awesome @nperez0111