Yes, once the page has loaded. The parser, the preview, the toolbar, the word counter, autosave and every export route are JavaScript that came down with the page and then runs on your machine. Switch to aeroplane mode mid-sentence and nothing changes. The preview still updates on every keystroke, and the download buttons still produce files, because those files are built in your browser.
It now survives a reload too. A service worker installs on your first visit and caches the editor shell: the page itself, the stylesheets, the fonts and the scripts. After that you can reload the tab, or open / in a fresh tab, with no connection at all.
The honest limit is that very first visit. Nothing is cached before it happens, so the first time you open the site you do need a network. The other limit is the rest of the site. The 50-plus guide and FAQ pages are not stored up front, so a page you have never opened will not load offline.
At a glance
| After the page loads | Typing, preview and export all work |
|---|---|
| Needs a connection | Only the very first visit |
| Offline install (PWA) | Yes, a service worker caches the editor |
| Guide pages offline | Only the ones you have already opened |
| Autosave offline | Yes, straight to localStorage |
| Remote images offline | Blank until you reconnect |
Why it keeps working when the network drops
- Visit the site once with a connection. That installs the service worker.
- After that,
/opens offline, and reloading the tab is safe. - Downloads work with no network, because each file is assembled in memory.
- Images pulled from a URL stay blank until you reconnect. Your Markdown is still correct.
- Guide pages are cached only after you have opened them, so browse before you disconnect.
The whole engine ships with the page. Parsing, preview, toolbar shortcuts, autosave and the .md and .html downloads are all JavaScript running in your tab. After the first load there is nothing left to ask a server for.
What the service worker keeps
A service worker is a small script the browser runs beside the page. Ours caches the editor shell on install: the homepage, the stylesheets, two web fonts, the icon and the scripts that do the parsing and sanitising. Those files are what the editor needs to start, so a cold start with no network works.
Everything else is cached the lazy way. Visit a page and it is stored as it loads, which means a second visit works offline. A page you have never opened was never stored, so it will not. Search results and any address with a query string are deliberately never cached, because a stale search is worse than an honest error.
This is not an offline mode bolted on top of a server app. It is a small addition to the architecture that already keeps your text private. Since your text never goes to a server, no server is needed to work with it.
What works with the network off
Feature by feature
Rather than generalise, here is the answer for a browser that has visited the site at least once before:
| Action | Works offline | Why |
|---|---|---|
| Typing and live preview | Yes | Rendering happens in your tab |
| Toolbar buttons and shortcuts | Yes | They only edit the text area |
| Autosave to localStorage | Yes | Browser storage is on your disk |
| Word, character and line counts | Yes | Counted locally on every keystroke |
| Download .md and .html | Yes | Files are built in memory, not fetched |
| Copy Markdown or HTML | Yes | Clipboard access is a browser feature |
| Print to PDF | Yes | Your operating system does the work |
| Reloading or reopening the editor | Yes | The shell is in the service worker cache |
| Dark mode toggle | Yes | The choice is read from your own browser |
| Highlighting, math and diagrams | Yes, if used once | Each library is cached the first time a document needs it |
| A guide page you have opened before | Yes | It was cached on that visit |
| A guide page you have never opened | No | Nothing was stored for it |
| Search | No | Search results are never cached, by design |
| Images referenced by URL | No | The picture itself lives on a remote host |
| Your very first visit ever | No | The cache is empty until that visit finishes |
One line to remember it by
Anything you have already loaded once keeps working. Anything the browser has never seen does not. The same rule explains why the preview feels instant on a good connection and on a terrible one.
The honest limits, spelled out
Three things still need a connection, and it is worth being precise about all three:
- The very first visit. The service worker cannot cache a site the browser has never fetched.
- Pages you have not read yet. Guides and FAQ answers are cached as you open them, not in advance.
- Anything hosted elsewhere. A picture stored on someone else's server cannot arrive while you are offline.
The first visit has to happen online
Nothing is on your device before you have loaded the site once. Open mdeditor.tw with a connection, let the page finish, and the shell is stored from then on. After that, reloading is safe and a new tab pointed at / opens fine with no network.
The guides are cached as you read them
Storing every page up front would mean downloading megabytes that most people never open, so the service worker does not do it. It caches each page the first time you visit it instead. If you want the cheat sheet available on a flight, open it before you take off. Search is the one exception that never caches: a stale result list is worse than an honest failure.
Anything remote stays remote
Images referenced by URL will not display in the preview while you are offline. The Markdown itself stays perfectly valid, and the pictures reappear once you reconnect.
Phones discard background tabs
A browser can drop an inactive tab to reclaim memory, and phones do it eagerly. Your draft survives that, thanks to autosave, and the tab now comes back from the cache when you return to it. Keeping the editor in the foreground during a long offline stretch is still the safest habit.
What goes wrong offline, and the fix
The broken image that is not broken
Suppose you are drafting documentation at 35,000 feet, and the preview shows a broken image icon where your diagram should be:
## Deployment flow
The build then promotes to staging.
Nothing is wrong with that Markdown. The parser produced a correct <img> tag. The browser simply cannot fetch a file from a host it cannot reach, so the preview leaves a gap. The real cost is that you can no longer tell whether the address is right.
Write it so the gap still reads
## Deployment flow
> TODO: confirm this image URL once back online.
The build then promotes to staging.
Descriptive alt text is good practice anyway. It is what a screen reader announces, and what shows when an image fails to load. A quoted TODO line leaves a marker you can search for later. The images guide goes further on writing alt text well.
Watch out: The second common offline mistake is wandering off the editor. Clicking a link to a guide you have never opened gets you the browser's offline error, and the back button is the fix. Reload itself is safe now, and so is closing the tab, because the shell and your draft both come back. If you want a checkpoint mid-flight anyway, press Ctrl+S and save a .md file.
A practical pre-flight checklist
Planning to write on a plane, on a train through the mountains, or anywhere with hostile Wi-Fi? Do this while you still have a connection.
- Open mdeditor.tw and confirm the preview responds to a keystroke. That installs the cache.
- Paste in any reference material you will need during the trip.
- Open the guide pages you expect to want, such as the cheat sheet. Visiting them is what caches them.
- If your document uses code, math or a Mermaid diagram, type one of each once. That pulls down the library it needs.
- Optional: turn off sleep on lid close for the journey.
Then write for as long as you like. Exports work offline, so you can drop .md checkpoints onto your disk during the session. When you land, everything is where you left it: in the tab and in localStorage. Any part of the full guide you did not open first is waiting whenever you are back online.
Installing it, and when a desktop app still wins
Add it to your home screen
The site ships a web app manifest alongside the service worker. Browsers that offer an install option, which includes Chrome and Edge on desktop and Android, will let you add the editor to your launcher or home screen. It then opens in its own window with no address bar. Nothing changes about how it works. It is the same cached shell in a different frame.
When a desktop editor still wins
If you write offline every day and work across many files at once, a desktop text editor with a Markdown preview extension is still the better fit. It reads and writes files in a normal folder, rather than one document at a time in browser storage. Nothing is locked in either direction, because .md is the same plain text everywhere.
The one-click middle path
Export a styled .html copy of a finished document before you disconnect. That file is fully self-contained, so it opens and reads correctly with no connection. It is a good way to carry reference material, though not a way to draft new work.
Offline capability rests on the same foundation as everything else here. See where your text is stored for the storage side, and why the editor is free for the cost side.
Related questions
Try the Editor
Open Editor