How We Test the Varnip Generators

Last updated November 2, 2026. This page lists what the Varnip tests check for each generator, how many cases they run, which software reads the files back, and what the tests cannot show. The counts were read from the test code on October 14, 2026.

How does Varnip test its generators?

Varnip tests each generator by making files for known inputs and reading them back with a software decoder, zxing-wasm. A read-back test passes only if the text that comes back is the text that went in. The barcode lines and the QR squares are drawn by other code than the decoder, so for them the reader is not the writer; the Data Matrix is the exception, as the limits section explains. The browser tests draw files in the Chromium, Firefox and WebKit engines. Before each release a single command runs every test and the other checks listed below, and a release does not go out if one of them fails.

How is the barcode generator tested?

The barcode generator is tested by drawing every format at every size and resolution and reading each file back. The generator makes four barcode types: Code 128, UPC-A, EAN-13 and EAN-8. The test draws each one at the three sizes of the Size menu (80%, 100% and 200% of the 0.33 mm bar) and at two resolutions (300 and 600 dpi). That is 24 combinations in each browser engine, so 72 PNG files and 72 SVG files in all. Each combination gives four reads: the PNG and the SVG, each with the decoder's try-harder setting on and off. That is 96 reads in each browser and 288 in all. The browser draws the PNG on a canvas, as yours does; the SVG is written by the generator's code in the browser and turned into an image for the decoder by a rendering library, Resvg.

What is measured in the files?

Besides reading each file back, the test measures the file itself: the resolution stored in the PNG, whole pixels for every bar, the bar width of the retail formats inside 80% to 200% of the 0.33 mm bar, the range in GS1 Canada's EAN/UPC Symbol Reference (2018), the blank margins (quiet zones), the SVG size in millimeters, and that the SVG holds no text elements.

What else is checked?

Unit tests check the check digit on three known numbers, refuse a wrong check digit and never correct it, and keep the text inside the symbol box for every format. They also check that a ZIP made by the page's ZIP writer passes the integrity test of unzip and 7-Zip, and that typed text never becomes markup in the preview (five hostile strings). The browser test of the page checks that the files the page downloads read back in every format, that a bulk run of 1,000 SVG files or 100 PNG files comes out whole, and that the 100th PNG in the ZIP reads back. On October 5, 2026, we also measured the PDF that Chromium's print makes: the 50 mm ruler measured 50.0 mm.

Are the one-format barcode pages tested the same way?

The Code 128, UPC and EAN-13 pages use the same barcode generator, locked to one format, so the tests above cover their files. On each of the three pages, in Chromium, Firefox and WebKit, a browser test also checks that the page opens with its own example and no format picker, and that the PNG and SVG files it downloads and one file from a bulk ZIP read back with the software decoder. The barcode and QR code page is checked the same way in both directions of its switch: each tool downloads a file that reads back, and the hidden tool takes no keyboard stop.

How is the QR code generator tested?

The QR code generator is tested by writing codes for sample texts, reading each one back, and checking the error correction level it carries. A set of 7 samples (a web address, digits, capital letters with symbols, text with accented letters, Japanese characters and emoji, a Wi-Fi network, a contact card, and text with spaces at both ends) is written at all four error correction levels, which makes 28 codes. Each one is turned into an image and read back, and the test fails unless the text matches exactly and the decoder reports the level that was chosen.

What do the browser tests add?

In Chromium, Firefox and WebKit, the test makes PNG files for four texts (a web address; one text with accents, Japanese characters and emoji; a Wi-Fi network; and a long text) at two error correction levels and two printed sizes (2 cm at 300 dpi and 5 cm at 600 dpi). That is 16 PNG files in each browser and 48 in all. Each file is checked five ways: the text reads back exactly, the level reads back as chosen, the squares are whole pixels and the image is square, the resolution is in the file, and the blank margin at the top and left is at least four squares wide. A unit test measures that margin on all four sides, the margin DENSO WAVE (2026) says a QR code needs.

Are all ten kinds of QR code read back?

All ten kinds are read back, but not all from the page. For five kinds (Website, Wi-Fi, Text, SMS and Location), the PNG and SVG files that the page downloads in Chromium, Firefox and WebKit are read back: 30 files. The other five kinds (Contact, Email, Phone, WhatsApp and Event) are read back in Node.js from the same code that builds their content, not from the download button on the QR code generator page.

How are tricky inputs tested?

Wi-Fi names are tried with 8 hostile cases that use the symbols ; , : \ and " inside the name. The text is run through our own re-implementations of how Android and the ZXing library read Wi-Fi codes, and the builder must warn in exactly the cases where an older Android reader fails. Contact cards (vCard) and calendar events are checked against 16 and 12 tagged cases, including a date line typed into an event's description, which must stay text and never become a second start date, and the hour that daylight saving time repeats. A Wi-Fi password never ends up in a file name.

Are the Wi-Fi, location and vCard pages tested?

Yes: on the Wi-Fi, location and vCard pages, in Chromium, Firefox and WebKit, a browser test checks that the page opens with its own example and shows no other kind of code, that the PNG and SVG files it downloads read back as the example, and that after a field is edited the new files read back as typed. The same test types into every one of these pages and checks that what was typed appears in no request, no count and no file name.

How is the GS1 Digital Link generator tested?

The GS1 Digital Link generator is tested with 33 cases: 21 inputs that must produce an exact address and 12 that must be refused with a reason. Each expected result comes from GS1: from the examples in its URI standard, from the tests of GS1's open-source engine, or from running that engine. The 12 refusals cover a wrong check digit, a batch or lot that is too long or holds a space or a forbidden character, a date that does not exist or is not six digits, and a batch without a GTIN. Each refusal shows up under the field it belongs to. The address format is described in the GS1 Digital Link URI syntax standard (2026).

How are the codes read back?

For 4 of the cases, the address is written as a QR code and read back as plain text. For 4 addresses, the Data Matrix is written, drawn as an SVG, turned into an image and read back as the same text. The Data Matrix test also checks that the symbol is square and that writing the same address twice gives the same symbol. For 3 sample addresses in both code types, at the page's default printed size of 2 cm and 600 dpi, every square stays inside 0.396 to 0.990 mm, the range in GS1 New Zealand's fact sheet on 2D barcodes (2025). In the three browsers, the QR code and Data Matrix SVG files that the page downloads are read back as the address shown on the screen.

What about the privacy of what you type?

The page test types a GTIN, a batch, a serial number, a date and a domain, then checks that none of them appears in any request the page makes, and that no request leaves the local test server.

How is the Data Matrix generator tested?

The Data Matrix generator is tested by writing four sample texts as a Data Matrix and reading each one back: a web address, a text with an accent and an emoji, a lot number with a slash, and a text of 1,500 letters. Each symbol is drawn as an SVG, turned into an image and read back by the software decoder, and the test fails unless the text matches exactly, the decoder reports a plain Data Matrix, and the blank margin is one square wide. A text too long for a Data Matrix must be refused with the words "too long". In Chromium, Firefox and WebKit, a browser test checks that the page opens with its example already drawn, that the PNG and SVG files it downloads read back, that there is no damage-protection control, and that the printed sizes are 2, 3, 5 and 10 cm. The software decoder is not a phone or a scanner: scan one printed code before you print many.

What runs before every release?

Before each release, one command runs these checks in order, and it stops at the first failure.

1. The Node.js version and the lock file are the expected ones.
2. The site's edge files (response headers and redirects) match the indexing setting.
3. The type check and the build of the site.
4. Every test file: the unit tests, the browser tests and the tests of the built pages.
5. A check that the built JavaScript runs in the browsers Varnip supports (ES2021).
6. Size budgets: no page ships more script than its budget.
7. Licenses: every font and every dependency that is served is registered with its license.
8. A scan of the files and of the whole history for secrets such as access tokens.
9. A security audit of the dependencies, where every high or critical advisory must be listed with a reason and a review date.

The tests of the built pages check, among other things, that every page has a canonical address and structured data, that the sitemap carries a date for each page, that no inline script or style would be blocked by the content security policy, and that the Worker that counts visits stores only a closed list of fields. On October 14, 2026, the nine test files that need no browser held 135 tests, and all 135 passed.

What do the tests not cover?

The tests have limits, and this page states them so you can judge the results.

• The Data Matrix is written and read by the same library (zxing-wasm). Its read-back shows that this decoder can read the file, not that two independent decoders agree. The QR code and barcode read-backs do not have this limit.
• The parsers that stand in for Android's Wi-Fi code reader, and for the ZXing library's Wi-Fi, email and text-message code readers, are our own re-implementations, not the original programs.
• The tests did not use a phone camera, a store scanner or a printed label. Outside the tests, on one Android phone, a reader app read a downloaded Code 128 PNG. Scan one printed code before you print many.
• The browser tests run the Chromium, Firefox and WebKit engines that the Playwright test tool installs, on a computer, not the browsers on your phone; no real iPhone was used.
• The GS1 Digital Link generator does not contact id.gs1.org or your domain. It checks the check digit of the GTIN, which is not the same as checking that a GTIN is registered or belongs to you. On October 14, 2026, our own check found that GS1's example GTIN 09520123456788 answered "Not Found" at id.gs1.org.
• The size of a printout depends on the print dialog. The print test measured the PDF that Chromium makes, not paper from a printer, so check the 50 mm ruler on your own print.

How do I report a mistake on this page?

You can write to hello@varnip.com. If a test described here does not match what you find on a generator, or you have a code that fails to read, send the input and the file type, and the one person who makes Varnip will read it. See the About page for who that is.