bndw/wifi-card: a print-and-tape QR card for your WiFi password

The problem wifi-card solves, and who actually has it

Reading a WiFi password out loud is a bad interface. It is long, it has ambiguous characters, and the person typing it is holding a phone. wifi-card takes the SSID and password you already know and renders them as a card with a QR code, which the README describes as something to tape to the fridge, keep in your wallet, or hang on the wall for guests at home or in a hotel. The intended audience is a host, not a network engineer: someone who wants a guest to join without a spoken password. The project itself is a small React app, and the repository topics list qrcode, react and wifi. It does not scan networks, discover SSIDs or talk to your router. Everything it prints comes from what you type into the form. That is the whole scope, and it is worth being clear about it before you install anything, because a tool with a narrow scope is only useful if your problem matches it exactly.

How wifi-card turns a form into a printable card

The mechanism is visible in package.json. The app is built with Vite and React 19, and the QR code comes from qrcode.react, which renders the code as a React component rather than generating an image server-side. There is no backend in the dependency list: no express, no database client, no API layer. i18next, react-i18next and i18next-browser-languagedetector handle the interface language, and the browser language detector picks the locale from the browser rather than from a server. The Dockerfile confirms the shape of the deployment: the first stage is node:24-alpine, it runs yarn install --immutable, then yarn prettier --check ./src, then yarn build. The second stage is nginx:stable-alpine, and the only thing copied across is /app/dist into /usr/share/nginx/html. So the runtime is a static bundle of HTML, JavaScript and CSS served by nginx. The SSID and password never leave the browser tab. That is a real property, and it is also the reason the project can advertise itself as not tracking you: there is no server code to send anything to.

Running wifi-card locally with make run

The README gives two paths. The first is the official Docker image on http://localhost:8080, started with a single make target. The Makefile builds the image tagged bndw/wifi-card:latest from the local Dockerfile and runs it with port 8080 mapped to port 80 inside the container, which is where nginx listens. If you have not built the image yet, build it first.

make build
make run

After make run, open http://localhost:8080 in a browser. You should see the wifi-card form. Enter your network name and password, and the card with the QR code renders in the page. The --rm flag in the Makefile means the container is removed when you stop it, so nothing persists between runs; the image stays until you delete it. For development, the second path is a live-reload server on http://localhost:3000, which requires yarn to be installed.

make dev

The dev target runs yarn followed by yarn start, and yarn start is mapped to vite in package.json. If you would rather not use Docker at all, yarn build produces the dist directory that the Dockerfile copies into nginx, so you can serve that directory with whatever static file server you already run.

Where wifi-card stops being the right tool

The card is a snapshot. It encodes the SSID and password as they were at the moment you printed it, and nothing in the repository suggests the card is regenerated or that the app keeps state between sessions. Rotate the WiFi password and every printed card is wrong, which is a worse failure than a spoken password because the person holding the card has no way to know why it stopped working. The second limitation is the input. The app does not read the SSID from the machine it runs on, so if you do not know the network name, the tool cannot help you find it. Third, the README does not document any way to export the card as a PDF or an image file; the workflow is a browser print dialog, and how the card lands on paper depends on your browser and printer settings rather than on anything the project controls. If you need a card that updates itself, or a tool that discovers the network, wifi-card is the wrong shape. It is a form plus a QR renderer, and it is honest about that.

wifi-card against a general QR code generator

The obvious alternative is any generic QR code generator, and the difference is not the QR code. A general generator takes an arbitrary string and draws it. wifi-card takes two named fields, a network name and a password, and formats them into the WiFi credential payload that phone cameras recognise as a join request rather than as plain text. That formatting is the product. If you use a general generator, you have to know the payload syntax yourself and get the escaping right, and a mistake produces a code that scans into a text note instead of offering to join the network. The trade-off runs the other way too: a general generator will happily produce a PDF, an SVG or a high-resolution PNG, and it will encode anything, including a network you are not on. wifi-card is narrower by design, and the narrowness is what removes the syntax mistake. For a one-off card for your own home network, that trade is worth taking. For anything that needs a file output or a batch of codes, it is not.

Maintenance, upgrades and the MIT licence

The repository is not archived, and the last push was on 2026-08-27. The dependency set is small and current: React 19, Vite 8, qrcode.react 4, i18next 25. There are no retrieved releases, so the project appears to be consumed from the master branch or from the Docker image rather than from versioned tags. That matters for upgrades, because there is no changelog to read before you pull. The Makefile has a publish target that pushes both the latest tag and a tag built from the short git SHA, so the SHA-tagged image is the closest thing to a pinned version and is the one to use if you want a build you can reproduce. The Dockerfile runs yarn install --immutable and a Prettier check on ./src before the build, so a build that breaks formatting fails rather than shipping. The licence is MIT, stated in package.json and present as LICENSE.md at the repository root. MIT permits commercial use and modification, and it comes with no warranty; if you redistribute the image or a modified build, keep the licence file with it. That is a description of the licence text, not legal advice.

Editorial conclusion

Use wifi-card if you want a printable QR card for guests and are comfortable that the SSID and password are typed into a browser tab, either on wificard.io or on your own container. Do not use it if you need a card that survives a password rotation without reprinting, or if you want the tool to read the network from the machine it runs on. Before adopting it, check src/translations.js for the language you need and confirm the Dockerfile's nginx image still matches your deployment target.

Frequently asked questions

Official sources

1. bndw/wifi-card on GitHub
2. Issues
3. License: MIT
4. Project website
5. README