When you write a heading in a notes app, there are two common experiences.
One is seeing a large heading right away—bold, links, and images already close to final layout. That’s usually called WYSIWYG (“what you see is what you get”). The other is seeing Markdown marks directly: a # before a heading, links keeping both text and URL, with layout shown in preview.
Neither is absolutely better. They prioritize different problems: WYSIWYG lets you see the result earlier; Markdown lets you see more directly how content is stored.
How Markdown, WYSIWYG, and rich text differ
WYSIWYG emphasizes that what you see while editing is close to the final result. Many rich-text editors work this way: you adjust headings, bold, color, and layout with buttons, without touching markup. Strictly speaking, “rich text” and “WYSIWYG” aren’t identical—but when people pick a notes tool, they often use both phrases for the same kind of visual layout experience.
Markdown uses a few visible characters for structure. For example, ## means a second-level heading, and **text** means emphasis. The source is still a text file; it has to be rendered before it becomes a web page or other laid-out result.
So the real difference isn’t only whether the UI looks polished:
- WYSIWYG prioritizes making the editing surface feel like the finished piece—good for people who want to tune visuals directly;
- Markdown prioritizes keeping the source visible—good for people who care about text processing, migration, and many outputs.
Rich text isn’t necessarily locked in, and Markdown doesn’t guarantee identical rendering in every tool. Whether formats travel still depends on how a product saves and exports.
How Abox Note edits and previews today
Abox Note’s editor faces Markdown text directly. There is no WYSIWYG editing mode. Syntax highlighting helps you spot headings, links, and code; the toolbar can insert common marks—but the marks themselves stay visible.
Reader-facing results live in a separate preview. That preview currently uses web rendering; the same content can also become a long image or a PDF. Authors work on content and structure in the editor, then check how it looks in a given medium via preview or export.
That isn’t ignoring layout. It separates “change the content” from “see the finished piece.” Web pages, long images, and PDFs have different layout needs; if the editor had to equal every final result at once, it would be hard to say which one was the true “what you see.”
Why Markdown, not rich-text editing
Abox Note cares most about one thing: authors can understand and take their prose with them.
When headings, lists, and links exist as text, find, replace, move, and export work on visible characters. Even if you later change themes, output formats, or text tools, the source doesn’t have to follow one particular layout UI.
That choice also draws a clear product boundary: the interface can offer highlighting, a toolbar, autocomplete, line numbers, and mobile editing aids—but those aids still act on Markdown text. Helpers can lower input cost; they shouldn’t make content recoverable only through hidden controls.
What this choice costs
Visible Markdown marks come with a learning curve. The first time, #, backticks, and link syntax may feel less obvious than format buttons. When you need to check complex tables, formulas, images, or page layout often, switching between edit and preview is also slower.
A toolbar and syntax hints can lower the bar; they can’t erase it. If your main need is freeform layout, fine-tuning font colors, placing content on a canvas, or collaborating around complex block structures, a WYSIWYG or rich-text tool is usually a better fit.
If you want the body to be readable, searchable, portable text first—and you’re willing to learn a few marks—Markdown gives more direct control.
Abox Note chooses the latter: see the content clearly while editing; see final presentation in preview. It isn’t an answer for every writing scenario. It’s a trade-off around how text is meant to be used over time.