# Are Online Markdown Editors Safe? What to Check

- Canonical URL: https://oka-project.com/en/blog/browser-markdown-editor-safe
- Published: 2026-09-12
- Author: oka (https://oka-project.com/en/about)
- Summary: Before pasting an unpublished draft into a browser editor, check where the text is processed, what the page can send, what it stores locally, and what the Network panel shows.
- Category: guide / Tags: Markdown, security, CSP, browser editor, privacy

---
A browser-based Markdown editor can be convenient when you do not want to install an app. But if the document is unpublished, confidential, or work-related, one question matters before the feature list: **where does the text go?**

You do not have to rely only on a sentence that says "processed locally" or "we do not upload your data." You can inspect how the page is built and what actually happens when you edit or export a harmless test document.

## What "safe" means in this article

Here, "safe" has a narrow meaning: **the editor does not unnecessarily send the Markdown body to an external service during normal editing, preview, or conversion.**

That does not mean a web app can guarantee the security of your entire device. The browser, operating system, extensions, shared profiles, and user actions are separate risks.

A practical review has four parts:

1. Where is the Markdown processed?
2. What outbound paths does the page allow?
3. What is stored in the browser?
4. What traffic actually appears during editing and export?

## 1. Separate "runs in a browser" from "processes locally"

Two browser editors can look nearly identical while using very different architectures.

### Server-side conversion

The editor uploads the Markdown to a server, where the server performs conversion or analysis and returns the result.

This may be necessary for some features, but the document leaves your device.

### Browser-side conversion

The application loads its code, then parses, previews, and generates files in the browser.

That means the core editing workflow does not require sending the Markdown body to a conversion API.

But local processing alone is not enough to prove that no other script can make outbound requests. That is why CSP and Network inspection matter.

## 2. Inspect the Content Security Policy

Content Security Policy (CSP) lets a page restrict sources and destinations that the browser is allowed to use.

A restrictive application may use a pattern such as:

```http:csp-example.txt
Content-Security-Policy:
  default-src 'none';
  script-src 'self';
  style-src 'self';
  font-src 'self';
  img-src 'self' data:;
  connect-src 'none';
  form-action 'none';
  base-uri 'none';
```

This is only an example. Real sites may need additional allowances.

The key point is to inspect the actual directives rather than checking only whether a CSP header exists.

### `connect-src`

This controls common script-initiated connections such as fetch/XHR, WebSocket, EventSource, and `sendBeacon()`.

If `connect-src` is omitted, it can fall back to `default-src`.

### `form-action`

This controls form submission destinations.

It does **not** simply inherit the restriction from `default-src`, so a strict policy should consider it separately.

### `img-src`

Markdown can contain remote images. Rendering them may create requests to other domains even when the Markdown itself is processed locally.

### `base-uri`

This controls the URLs allowed in a document's `<base>` element and is another directive that should be considered separately in a restrictive policy.

## 3. Check the Network panel yourself

The browser's Network panel is one of the most useful practical checks.

### Step 1: load the page, then clear the log

The initial page load will normally fetch HTML, JavaScript, CSS, and other app resources. Clear those requests after the page is ready.

### Step 2: use a harmless unique test string

Do not test with real confidential information.

For example:

```text:test.txt
MARKDOWN-NETWORK-TEST-2026
```

### Step 3: perform the actions you care about

Try previewing, exporting, or converting the test document.

### Step 4: inspect new requests

Check:

- destination domain
- HTTP method
- request payload
- query parameters
- whether the test text appears in a request

If nothing document-related appears, you can say that no document transmission was observed for those tested actions at that time.

That is evidence, not a permanent proof of every feature or future version.

## 4. Check browser storage separately

An editor may save a draft to `localStorage` or IndexedDB so the text survives a refresh.

That is different from uploading it to a server, but it still matters on shared devices.

For sensitive drafts, check whether the editor:

- stores the document locally
- offers a clear way to remove it
- restores it automatically
- is being used in a shared browser profile

## Risks outside the main CSP check

### External images are an easy-to-miss network path

Consider this Markdown:

```markdown:image.md
![image](https://example.com/tracking.png)
```

If the preview loads the remote URL directly, the browser sends a request to that host.

That is why an editor can truthfully parse Markdown locally and still make external requests caused by document content.

A privacy-conscious renderer should treat remote resources deliberately rather than assuming "no API upload" covers every outbound path.

### Browser extensions are outside the page's CSP boundary

CSP constrains the web page. It does not automatically control every browser extension installed by the user.

An extension with broad permissions may be able to read page content.

For high-sensitivity documents, review extensions with permissions such as access to all site data, use a dedicated browser profile, or avoid web tools if organizational policy requires a more controlled environment.

### Treat AI features as a separate data path

An editor can keep ordinary Markdown editing local while sending text only when the user explicitly invokes an AI feature.

If an editor includes AI assistance, check:

- whether normal editing sends anything
- whether AI is opt-in per action
- what portion of the document is sent
- which provider receives it
- whether the user is told before transmission

Do not assume the data path for AI features is the same as the data path for local preview or export.

## How Yomu approaches the problem

[Yomu](https://oka-project.com/en/tools/markdown-editor) is designed to edit and convert Markdown in the browser for its core workflow rather than send the document body to a conversion server.

It also uses CSP to narrow unnecessary outbound paths. That makes the privacy claim more inspectable, but the same rule still applies: check the delivered policy and actual network behavior rather than treating any product statement as a complete security proof.

If you only need to open a Markdown file without editing it, [Markdown Viewer](https://oka-project.com/en/tools/markdown-viewer) is the simpler tool.

## A practical checklist

Before pasting a sensitive draft into an online Markdown editor, check:

1. Is Markdown processing local or server-side?
2. What does `connect-src` allow?
3. Can remote Markdown images be fetched?
4. Is `form-action` restricted?
5. Is `base-uri` restricted where appropriate?
6. What new traffic appears during editing and export?
7. Is the draft stored in local browser storage?
8. Do installed extensions have broad page access?
9. Do AI features send text to another service?
10. Does your organization's policy allow this workflow?

## Summary

Do not reduce the decision to "online is unsafe" or "CSP means safe."

A stronger assessment asks where the Markdown is processed, which outbound destinations the browser allows, what is stored locally, and what network traffic occurs during the exact operations you plan to use.

For highly confidential documents, organizational policy and endpoint security matter more than any single web-app architecture.

### References

- [MDN: Content-Security-Policy default-src](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/default-src)
- [MDN: Content-Security-Policy connect-src](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/connect-src)
- [MDN: Content-Security-Policy form-action](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/form-action)
- [MDN: Content-Security-Policy base-uri](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/base-uri)
- [W3C: Content Security Policy Level 3](https://www.w3.org/TR/CSP/)