Markdown preview

Markdown preview places source text and rendered output beside each other on wider screens. As you type, the page sends the current Markdown string through the marked parser, converts it to HTML, and then sanitizes that HTML with DOMPurify before inserting it into the preview. There is no run button. Headings, paragraphs, emphasis, links, block quotes, lists, code spans, code blocks, and other syntax recognized by the installed parser can appear immediately. The source stays editable, so a formatting change can be checked without replacing the draft.

The preview answers a specific question: how this browser session interprets the entered Markdown under the application's current parser and sanitizer configuration. Markdown has several dialects, and another destination may render the same source differently. A README on a code host, a static-site generator, a chat application, and a documentation platform can enable different extensions or filtering rules. Use the preview to catch structure and syntax mistakes, then verify important documents in the platform where they will be published.

A compact test can reveal most formatting assumptions. Start with # Release notes, add a plain paragraph containing *emphasis* and **strong text**, then add a link such as [documentation](https://example.com). Follow it with a three-item list and a fenced code block. If each structure appears as expected, paste the longer draft. Small tests are easier to diagnose because a missing space after a heading marker or an unclosed code fence is visible near the place where rendering changes.

For nested content, indentation matters. A continuation paragraph or code block under a list item needs enough leading spaces for the parser to associate it with that item. Blank lines separate blocks and often decide whether text becomes a new paragraph or stays attached to a list. Backticks protect inline code from emphasis parsing, while fenced blocks preserve a larger code sample. The preview does not edit the source to repair syntax. It shows the parser's result, leaving the author to decide which source change best matches the target platform.

A Markdown link has visible label text and a destination. Review both. A label can look trustworthy while pointing somewhere unexpected, and a relative URL may work only within a repository or site with the right base path. The preview can show link styling, but it cannot prove that a remote destination is available, safe, permanent, or correct for the final deployment. Test important links in their publishing environment and use descriptive labels that still make sense outside the surrounding sentence.

Markdown parsers may accept raw HTML, but this preview sanitizes the generated HTML before display. Sanitization can remove elements, attributes, or URL forms that are considered unsafe by the active DOMPurify configuration. That is a protection boundary for this preview, not a promise about another Markdown renderer. A destination that permits raw HTML could retain content removed here, while a stricter destination may remove more. Avoid depending on raw HTML when portable Markdown is required, and never infer another platform's security behavior from this page alone.

Markdown uses ordinary punctuation as syntax, so literal characters sometimes need a backslash or code span. An asterisk intended as a visible symbol can start emphasis. A leading number followed by a period can start an ordered list. A greater-than sign at the beginning of a line can create a quote. Backslash escaping works for many ASCII punctuation characters, but behavior around HTML and extended syntax varies. When a symbol disappears or changes style, reduce the line to the smallest example and test escaping it or wrapping it as code.

Line endings and blank lines affect blocks more than many authors expect. A single newline inside a paragraph may render as a space, while a blank line starts a new paragraph. Trailing spaces can request a hard line break in some dialects but are difficult to see and easy for editors to remove. Tabs can produce different indentation than spaces. The preview uses the exact current input, including invisible whitespace. If a section shifts unexpectedly after paste, inspect indentation and blank lines before changing unrelated punctuation.

Parsing and sanitization occur in the browser. The source is not sent to a PWRKIT processing server to create the preview, and rendered HTML is held in the page's current state. The preview updates after each input change, and a delayed analytics outcome records bounded length information rather than the draft text. Reloading the page normally clears the unsaved source. There is no account, autosave, revision history, conflict resolution, or recovery workflow, so the workbench should not be the only location of an important document.

Keep sensitive drafts in an approved editor and paste only what policy allows. Local browser work can still be observed by extensions, device-management software, screen capture, clipboard history, or someone with access to the session. Sanitization protects the preview from many unsafe HTML constructs, but it is not encryption and does not classify confidential information. The page also does not fetch linked images or documents as part of a content audit. Remote resources referenced by the rendered output may be requested by the browser according to normal browser behavior and sanitizer decisions.

The page is not a full Markdown editor or publishing system. It has no syntax toolbar, file import, front matter validation, table-of-contents generator, spelling review, link checker, image uploader, diagram engine, or repository integration. It does not know a site's theme, heading anchors, custom components, shortcodes, or build plugins. Syntax that depends on those extensions may appear as plain text or produce a different structure. Generated HTML is used for the preview, but the interface does not currently provide that HTML as a separate copyable result panel.

Sanitized rendering does not certify source as safe for every destination. The final application may use another parser version, another sanitizer policy, or no sanitizer at all. The preview also cannot judge accessibility by appearance. Heading levels can skip logical order, links can use vague labels, images can lack useful alternative text, and tables can be hard to navigate even when they look correct. Review document structure and semantics separately. For critical publishing flows, run the destination's own build and automated checks before approval.

When formatting changes far below the line you edited, look for an unclosed fenced code block, unmatched emphasis delimiter, incomplete link, or HTML tag earlier in the source. Remove half the draft or test sections independently to locate the first point where output differs. If a heading renders as text, add a space after the hash characters. If a list will not nest, use consistent indentation and include blank lines where the target dialect expects them. If code is being interpreted as Markdown, use matching backticks long enough to contain any backticks inside the sample.

If HTML disappears, assume the sanitizer removed it until a minimal test shows otherwise. Do not work around sanitization with obfuscated markup. Replace the structure with Markdown or use a trusted publishing component designed for that requirement. If the preview stops updating, save the draft elsewhere, reload the page, and test a short heading. Browser extensions that modify page content can interfere with editable fields. A difference between this preview and a repository host is usually a dialect or extension difference, so reproduce the issue in the final renderer before changing valid source.

Read the rendered document in order and compare it with the source. Check that there is one clear primary heading when the destination expects it, heading levels descend logically, list nesting matches the argument, code blocks preserve indentation, and links use correct labels and targets. Verify that literal punctuation was not consumed as syntax. Resize the page to catch wide code blocks or tables that cause horizontal overflow. Then open the same draft in the actual destination, since repository-specific alerts, task lists, footnotes, or heading anchors may not match this preview.

HTML escape is useful when documentation must show raw markup literally rather than render it. Word counter measures words and characters, including field-length checks, but does not test Markdown structure. URL encode prepares one value for a URL component; it should not be applied to an entire Markdown link indiscriminately. Markdown preview is the correct choice for fast visual feedback on source syntax, with sanitization as a local preview safeguard and destination testing as the final authority.

Prefer syntax supported by the destination's documented dialect. Standard headings, paragraphs, links, lists, quotes, and fenced code usually travel more reliably than embedded HTML or platform-specific extensions. When a document must work in several systems, create a sample that covers every construct you plan to use and compare all renderers before drafting the full piece. Record any accepted differences, such as task-list controls, table alignment, automatic link creation, or heading identifiers, so later editors do not mistake them for broken source.

Keep line wrapping separate from semantic line breaks. Let an editor wrap long prose visually instead of inserting hard newlines solely to fit a window, unless the repository style requires source wrapping. Preserve code indentation exactly and label fenced code languages only when the destination supports the label. Before moving the draft, save the Markdown source itself rather than copying from the rendered preview. Copying rendered content can discard syntax, rewrite links, or bring formatted HTML that behaves differently when pasted into another editor.