a code you make yourself.
most qr generators online send your content to their server, render it there, and hand back an image — which is fine for a url and less fine for a wifi password.
several also produce "dynamic" codes that redirect through their domain, which means the code stops working when they decide it does.
a page that encodes in your own browser has neither problem. nothing is transmitted, nothing expires, and the code points at exactly what you typed.
encoded locally, pointing straight at your content.
01 / what it istwo things make a self-hosted generator worth the trouble. what you encode never leaves your machine, which matters for a wifi password or an internal address. and the code points directly at your content rather than through somebody’s redirect, so it works for as long as your content does.
the encoder has to be in the file. a page that loads a library from a cdn is making a network request, and while that particular request does not carry your content, it does mean the page breaks when the cdn does — so the prompt asks for the algorithm implemented or vendored inline.
- codes for the content types you actually need
- encoding that happens in the page, not on a server
- a size and error-correction level you control
- download as png and as svg
- a print layout, for signs and labels
- what it encodes
- urls, plain text, wifi credentials, contact details, phone numbers — whichever you asked for
- where encoding happens
- in your browser. nothing is sent anywhere
- output
- png and svg download, and a print layout
- what it is not
- a scanner, a link shortener, or anything that tracks scans
see one in action.
02 / examplethe encoding happens in the page. nothing you type is sent anywhere, which is the reason to use this one for a wifi password.
copy this, then make it yours.
03 / starting prompta starting point, not a template — the point of an agent is that the result is yours. change the sections to match what you want, and remove anything you don’t need.
Build me a QR code generator as a single web page that runs entirely in the browser.
Ask me first:
- What kinds of content I need codes for: a url, plain text, wifi credentials, a phone number, contact details.
- Whether I need to control size, margin, or error correction level.
- What formats I want to download.
- Whether I need a print layout, for example a sheet of labels or a single sign.
IMPLEMENTATION — THIS PART MATTERS
- The QR encoding must happen in the page. Implement the encoder inline, or vendor a known-good implementation directly into the file.
- Do not load a library from a CDN, do not call an image-generation API, and do not make any network request at all. Both the privacy argument and the works-forever argument depend on this.
- Generate SVG, and offer PNG rendered from it in the browser. Do not ask a server for either.
- Test the output. Generate a code and confirm it scans before telling me it is finished — a QR generator that produces an unscannable code is worse than useless, and it looks fine.
WHAT IT DOES
- Pick a content type, fill in the fields for it, and see the code update live.
- For wifi: network name, password, security type, and hidden-network flag, assembled into the correct wifi string format.
- Error correction level selectable, with a plain explanation of the trade-off — higher correction survives damage and makes a denser code.
- Adjustable size and quiet-zone margin.
- Download as SVG and as PNG.
- A print view if I asked for one.
DESIGN
- One screen: input on one side, the code on the other, updating as I type.
- Show the code large enough to scan directly from the screen.
BE HONEST ON THE PAGE
- State that everything is encoded locally and nothing is sent anywhere. That is the reason to use this rather than a website, so say it plainly.
- Note that codes are static and point directly at the content — they cannot be edited after printing, and there is no redirect to change later.
- Do not claim scan tracking, analytics, or dynamic codes.
DELIVERY
- Produce one self-contained HTML file. Inline the CSS and JavaScript.
- No build step, no server, no framework, no package install, no external
requests at runtime.
- Mobile-first and responsive; it has to be usable one-handed on a phone and
still look right on a laptop.
- Accessible: semantic HTML, real contrast, visible keyboard focus, labelled
controls, touch targets big enough to hit, and respect reduced-motion.
- Use placeholders where information is missing. Do not invent facts, numbers,
names, dates, prices, or results I have not given you.
- Before you call it finished, use it yourself: enter real-looking data, reload
the page, and confirm nothing is lost or mangled.
PUBLISHING
Publish the finished page to HTMLShare and give me the link.
Use exactly one of the two paths below, preferring the first. Make the call
directly. Do not route it through a code sandbox, container, or computer-use
session — that is where the request gets blocked, and it is never necessary.
1. An HTMLShare integration or connector, if you have one configured.
The page is permanent and owned by my account. Report the url and the
siteId. There is no claimUrl or manageToken on this path — do not go
looking for one, and do not switch paths in order to produce one.
2. Otherwise, publish anonymously over REST. No account, key, or signup is
needed:
POST https://api.htmlshare.net/v1/publish
content-type: application/json
{"html": "<!doctype html> ... "}
The reference is https://htmlshare.net/docs and, for the full schema,
https://api.htmlshare.net/openapi.json
Report these from the response, in your reply and never inside the page:
url the public page
claimUrl a private link that is mine alone. opening it is how I keep
the page past its 24-hour expiry, or set an email reminder
before it goes. it carries the manage token, so it must
never appear in the published HTML or anywhere a visitor
could see it.
manageToken the only thing that can edit or delete this page later. it is
returned once and never again, so tell me what it is.
Tell me which of the two you used. If the path you reach for first is
unavailable in your environment, say so and tell me what you are switching to
before you publish — a permanent page on my account and a 24-hour anonymous
page are different things, and which one I get is my decision, not a detail.
If I ask for a change afterwards, update the existing page instead of
publishing again, so the URL I have already shared keeps working — through the
same integration on path 1, or with the manage token as an X-Manage-Token
header on path 2.
RECIPE MARKER
Include this tag in the <head>, exactly as written:
<meta name="htmlshare-recipe" content="qr-code-generator">
It tells htmlshare which recipe the page came from, so the library can count
that this one was actually made. It carries nothing else.give it a url.
04 / publishing ithow you publish depends on how you’re working.
- with an integration
- if your assistant already has htmlshare connected — mcp or another supported integration — just ask it to publish the finished page and hand back the url. the page belongs to your account and is permanent. when you want a change, ask for an update to that same page rather than a new one.
- with no integration
- the prompt tells the assistant to post the html to the rest api instead, which needs no account and no key. it comes back with a live url you can open immediately, a private claim link, and a manage token. the claim link is how the page stops being temporary — keep it.
- by hand
- nothing stops you doing it yourself: have the assistant give you the html file and drop it on the htmlshare home page. same url, same page, one more step.
- what matters here
- you will want this occasionally and urgently, usually while printing something. claim it so it is findable, and remember the codes it makes are just images — nothing about them depends on this page continuing to exist.
the codes outlive the generator either way.
05 / keeping it aroundgenuinely usable: make your codes, download them, and the images keep working even after the page stops serving 24 hours later.
claim it if you make codes regularly. the generator is the thing worth keeping; the codes themselves are files you already have.
- keep it around
- you need this occasionally and at short notice, which is exactly when a page that expired is annoying.
- custom url
- findable when you need it, which is always while you are in the middle of printing something.
- stable updates
- add a content type you did not think of, at the same address.
questions.
06 / questionsis what i encode sent anywhere?
no, if it is built as the prompt specifies — the encoding happens in your browser and the page makes no network requests. that is the reason to use this for a wifi password rather than a website that renders codes server-side.
can i change where a code points after printing it?
no. these are static codes pointing directly at your content. dynamic codes work by redirecting through someone else’s domain, which is the thing that later stops working — if you need editability, point the code at a page you control and change that page.
can it scan codes as well?
that needs camera access and a different kind of page. it is possible, but ask for it deliberately rather than expecting it — generating and scanning are separate jobs.
why not use a free qr website?
many of them upload your content, and several produce codes that route through their domain and expire. for a url on a poster that may be fine; for anything you would not paste into a stranger’s form it is not.