You can embed images in a document by linking to them, and mdbin takes care of serving them safely. Because every document is untrusted input shown in someone else's browser, images get the same security-first treatment as everything else: we never load a third-party image directly into a reader's page. Instead, mdbin fetches it for you, checks it, and re-serves it from our own infrastructure.
Embedding an image
Use standard Markdown image syntax — an exclamation mark, alt text in brackets, and the image URL in parentheses:

Reference-style images work too, which is handy when you reuse the same image or want to keep URLs out of the prose:
![Architecture][arch]
[arch]: https://example.com/architecture.png
The image must be reachable at a public https:// (or http://) URL. Supported formats are
PNG, JPEG, GIF, WebP and AVIF.
What happens to your image
mdbin never lets the reader's browser talk to the URL you pasted. Two things happen instead:
- While you're writing, the preview loads each image through a same-origin proxy: our server fetches it, validates it, and streams it back to you. (You'll need to complete the one-time human verification on the page first — see below.)
- When you publish, mdbin fetches each image once, re-encodes it, and stores its own clean copy. Published documents then load images from our CDN — not from the original host.
This means a published document keeps working even if the original image later disappears, and readers never depend on (or reveal anything to) the site you originally linked.
Why we proxy images
Loading a third-party image directly would quietly undermine the guarantees in Principles:
- Reader privacy. A remote image is a tracking pixel: it would leak every reader's IP address, browser, and the page they're viewing to whatever host the author chose. Proxying means readers only ever talk to mdbin.
- A tight security policy. Our Content-Security-Policy only allows images from mdbin itself and our CDN. We never widen it to "any website," so a document can't use an image tag to reach arbitrary servers.
- No surprises. Stored copies don't break, can't be swapped out after the fact, and aren't subject to someone else's hotlink rules.
How we prevent abuse
An image proxy that anyone can use is a tempting target, so it's heavily defended:
- No reaching internal systems (SSRF). Every image URL is resolved and checked before we
connect, and we pin the connection to the address we verified — so a URL can't be pointed at
localhost, a private network, or a cloud metadata endpoint, even via DNS tricks or redirects. - Strict size and dimension limits. Downloads are capped and aborted mid-stream if they run over, and images with absurd pixel dimensions are rejected — so a tiny file can't expand into a memory bomb.
- Real images only. We inspect the actual bytes, not the file extension or what the server claims. Anything that isn't a genuine allowed image type is rejected. SVG is not supported, because SVGs can contain scripts.
- Re-encoded and stripped. Stored images are re-encoded from scratch, which removes EXIF and location metadata and neutralises any file that tries to be both an image and something dangerous.
- Rate and bandwidth limits. Image requests are limited per IP, both by request count and by total bytes, to prevent the proxy being used to push traffic on someone else's behalf.
- Human verification. Loading images in the preview, and publishing, both require a quick proof-of-work check (the same ALTCHA challenge used elsewhere). It's invisible for real people but makes automated abuse expensive.
Good to know
| Supported formats | PNG, JPEG, GIF, WebP, AVIF |
| Not supported | SVG (security), and non-image files |
| Max size | ~5 MB per image |
| Per document | up to ~20 images |
| Verification | required to preview images and to publish |
A few practical notes:
- If an image hasn't been verified yet, or the original URL was unreachable when you published, it shows as a small placeholder rather than loading.
- Data URLs (
data:) and links relative to your document are left untouched — only externalhttp(s)images are proxied. - Everything you wrote is always recoverable verbatim from the document's Raw view; proxying only changes how images are served, never the Markdown you saved.