flyer
Share a single HTML file, or a PDF, at a short public link. No account, no API key, nothing to install. The link expires on its own.
npx flingflyers report.html --persist
https://flingflyers.com/p/x7Kp2mQ (copied to clipboard)
persisted · 4210 bytes · expires 2026-08-01T09:14:00.000Z
That is the entire product. You made an HTML file; now someone can open it in a browser on another device without you sending them the file.
Needs Node 22 or newer. Zero dependencies. Nothing to sign up for.
There is one question, and it decides everything else: can you run a command?
You have a shell
Use the CLI. Terminal, coding agent, CI, anything with
npx. Nothing to install or connect, and it is the only route that
can encrypt.
You don't
Use the connector. Claude on a phone or in a browser has no shell, so a remote MCP server is the only way to publish from there.
npx flingflyers page.html --persist # host for 7 days, print the link, exit npx flingflyers page.html # serve live from this terminal npx flingflyers page.html -e --persist # encrypted; the key stays in the link cat page.html | npx flingflyers - --persist # read from stdin
Hosted, or live
Hosted (--persist) uploads the file and exits. The link
keeps working with nothing running. Seven days by default,
--ttl 24h|7d|30d, thirty days maximum. This is almost always what you
want.
Live (no flag) stores nothing on the server. The process stays in the foreground and answers each visitor from the file on disk, re-reading it every time — so you can edit and refresh. Ctrl-C kills the link. Good for a demo you are still changing; wrong for anything someone opens later.
A live link can become a hosted one at any point and the URL does not change. That is the part worth knowing: you can share the link first and decide later whether it should outlive your terminal.
Scripting
--json prints exactly one JSON object on stdout and nothing else.
Errors go to stderr with exit code 1.
$ npx flingflyers report.html --persist --ttl 24h --json
{"id":"x7Kp2mQ","url":"https://flingflyers.com/p/x7Kp2mQ","mode":"blob",
"encrypted":false,"sizeBytes":1204,"expiresAt":1752950000,
"expiresAtIso":"2026-07-19T18:33:20.000Z","host":"https://flingflyers.com"}
Afterwards
| flingflyers ls | list your flyers and their state |
| flingflyers revoke <id> | kill a link now |
| flingflyers persist <id> | re-upload after editing, and reset the expiry |
| flingflyers resume <id> | reconnect a live host |
There are no accounts. Ownership is a token in
~/.config/flyer/pastes.json, so these only work from the machine that
created the flyer.
For anything without a shell. Add this as a custom connector in Claude and
publish_flyer becomes available in any conversation, on any device.
https://flingflyers.com/mcp
Streamable HTTP, no authentication, no account. Three tools:
publish_flyer, update_flyer — which revises a page you already
published without moving its link — and revoke_flyer. Listed in the MCP
registry as com.flingflyers/flingflyers.
The connector publishes plain flyers only. Your document reaches the server as text, so the encryption key cannot be created on your machine — which is the only thing that makes it worth having. For an encrypted flyer, run the CLI locally.
If you are not on Node and don't want a connector. Nothing to authenticate to create a flyer.
POST /api/pastes {"encrypted": false} → {id, ownerToken, urls}
POST /api/pastes/:id/persist body = the bytes; Authorization: Bearer <ownerToken>
DELETE /api/pastes/:id Authorization: Bearer <ownerToken>
GET /p/:id the flyer
ownerToken comes back once and is the only proof of ownership. Keep it
if you want to revoke or update later.
Agent-readable version of this page: /llms.txt.
- 5 MB per file. HTML and PDF only — this is not file hosting.
- One self-contained document. Inline your CSS, JS and images, or use data URIs;
a reference to
./style.csswill not resolve. - Thirty days maximum. Nothing here is permanent, by design.
- No access control. Anyone with the link can read the page.
Encryption with -e means the file is encrypted on your machine and the
key travels in the part of the URL browsers never send to a server. So the host stores
ciphertext it cannot read. But the host also serves the code that decrypts, so the
honest claim is an honest host can't read your content — not that a
malicious one couldn't. And anyone you give the full link to can read it.