Why I Built Marksafe: A Safer, More Flexible Alternative to Markdown

Title: Why I Built Marksafe: A Safer, More Flexible Alternative to Markdown

Introduction
Markdown is a fantastic tool for formatting content, but it comes with limitations and security risks. As a developer and content creator, I wanted a more powerful yet secure alternative—so I built Marksafe.

What is Marksafe?
Marksafe is a lightweight, XSS-safe alternative to Markdown, designed for developers and content creators who need more flexibility without the security risks of raw HTML.

• Secure by Design: No need to sanitize user input manually.
• More Powerful than Markdown: Supports attributes, custom styling, and enhanced formatting.
• Concise Syntax: Reduces boilerplate compared to HTML.
• Lightweight and Fast: Small footprint and optimized performance.

Why Not Just Use Markdown?
While Markdown is great, it has some major drawbacks:

• Limited control over attributes (e.g., no inline styles, classes, or data attributes).
• Requires extensions for extra functionality.
• Can be vulnerable to XSS attacks if improperly sanitized.

How Marksafe Solves These Problems
Marksafe gives you the power of HTML with a Markdown-like simplicity, while keeping security in check. Here’s a quick comparison:

Feature	Markdown	Marksafe
Secure by default	❌ No	✅ Yes
Supports attributes	❌ Limited	✅ Full control
Custom styling	❌ No	✅ Yes
Nested elements	❌ Limited	✅ Flexible

Marksafe Syntax in Action
Instead of writing verbose HTML, Marksafe lets you do this:

[div]
  class=container,,
  [h1] Welcome to Marksafe! [/h1]
  [p]
    This is the first paragraph. ;;
    This is the second one. ;;
    This is the third. ;;
    Then the 4th.
  [/p]
[/div]

This prevents XSS vulnerabilities while still allowing attributes like class, style, and data-*.

Who Should Use Marksafe?

• Developers building CMS platforms or documentation sites.
• Writers who need more flexibility in their content.
• Security-conscious teams who want safe formatting options.

Try Marksafe Today!
Marksafe is open-source and available on GitHub and npm.

💬 What do you think? Would you switch from Markdown to Marksafe? Let’s discuss in the comments!

Comments

[Remo Dentato]

I don't get it. Using one of your examples, you claim that:

[h1]Shopping List[/h1]

[p]Here’s a list of things to buy:[/p]

[uli]Apples;;Bananas;;Carrots
  [uli]Carrot A;;Carrot B
    [uli]Carrot B1;;Carrot B2[/uli]
  [/uli]
;;Dates[/uli]

[p]For more details, visit [a]href=https://example.com,,Example[/a].[/p]

[bq]This is a blockquote.[/bq]

is safer than:

# Shopping List

Here’s a list of things to buy:

  - Apples
  - Bananas
  - Carrots
    - Carrot A
    - Carrot B
       - Carrot B1
       - Carrot B2
 - Dates

For more details, visit [Example](https://example.com)

 > This is a blockquote.

Can you elaborate?
Markdown is born to help creating simple documents that can be rendered in different ways (HTML is one).
It seems to me you're creating another markup language much more similar to HTML than Markdown but I might have missed something.

[mksunny1]

My bad, I did not respond to this the whole time. But as they say, better late than never. You did miss a few important points there. Markfafe comes directly from HTML and is not an effort to build a new markup language. It is an effort to let your users effectively write HTML without your having to worry about the security implications; it doesn't allow javascript in and so provides full defence against XSS while allowing richer expression for users (attributes, styles etc), if they know HTML, that is...

[frank]

The interesting boundary here is the attribute model. Allowing class, style, data-* and URL-bearing attributes can be safe only if each value has an explicit policy; blocking JavaScript syntax alone does not cover dangerous URL schemes, CSS-based effects, or DOM clobbering through id/name. A useful way to substantiate “secure by design” would be a differential test suite: parse hostile inputs, serialize them, then assert the browser DOM contains no event attributes, unsafe protocols, or attacker-controlled named properties. That would make the security claim verifiable rather than syntax-dependent.