Need offline Windows barcode software?

The online barcode generator stays free and browser-based. This page is a demand test for a separate paid Windows app for places where the internet cannot be part of the critical path: warehouses, data centers, small shops, back offices, locked-down laptops, and production floors.

What the Windows version would be for

The web tool is right when you need a barcode image, a verified check digit, or an occasional sheet of labels. A Windows version starts to make sense when barcode work becomes operational: you need the tool available after install, behind a firewall, during an outage, or on a machine that operators use all day.

• Generate common retail, warehouse, book, and internal barcode formats without internet.
• Keep templates, presets, and a private barcode library on the local machine or network.
• Import CSV or spreadsheet-style lists for batch labels without uploading data.
• Print Avery-style sheets and custom label grids for office printers.
• Export verified SVG, PNG, and vector PDF files for designers, printers, and scanners.
• Keep the same plain-language validation and production warnings as the browser version.

What it would not replace

It would not issue GS1 numbers, certify a physical print, or pretend to be a full enterprise label-management system. If your operation needs ERP/database integration, thermal-printer command languages, approval workflows, or regulated label templates, dedicated industrial software is still the honest category to evaluate.

What the browser version already does

Before weighing an installed application it helps to be exact about what the web tool does on your own device, because the demand test above only makes sense against that baseline. Every barcode this site produces passes through two pieces of software with two distinct jobs. Rendering — turning an accepted payload into a symbol's bar pattern — is done by JsBarcode, an MIT-licensed open-source library, pinned to an exact version and used unmodified. Everything around the rendering is this site's own verification layer, implemented independently from published algorithm descriptions: one part runs before the renderer and decides what the symbol will carry, the other runs after it and reads the result back. Inputs never leave your device; there is nothing server-side to verify or log. The sections below follow one number through that pipeline, and every figure in them is computed at build time by the same code that runs in your browser.

Go deeper: the guide How the verifier decodes what you see walks the whole pipeline through cited and fictional inputs, including the exact comparison a decoder's reading must pass. The guides hub covers the other engines.

Validation before any bars are drawn

The validator does four things, in order. It normalises the input: spaces and hyphens are stripped from digit strings, an ISBN's hyphens and trailing x are tidied, Code 39 letters are uppercased. It enforces the selected symbology's length and character rules. It computes or verifies the check digit with its own arithmetic — data digits in, check digit computed and appended; complete number in, final digit verified. And it reports what it did in a note beneath the barcode, so nothing is applied invisibly. A mismatch stops the flow and no bars are requested from the renderer.

Take a cited reference vector, the data digits 400638133393 from a published EAN-13 check-digit walkthrough. Entered as twelve digits on the EAN-13 generator, the engine runs in its computed mode and the note reads:

Now a fictional misread: position 8 of the complete number, a 3, is entered as 8, giving 4006381833931. The verifier recomputes the check digit from the first twelve digits — they require 6, the number ends in 1 — and refuses:

The typo sits in a data digit, yet it is the check digit that no longer fits. That is why this engine never substitutes the digit that would make the number valid: a quietly corrected check digit turns a detectable error into a structurally valid number for the wrong item. Mismatches are reported, never repaired, and the error offers only the honest routes — fix the number, or hand over the data digits and have the check digit computed.

Normalisations are disclosed, not applied silently

The same policy covers every change the validator makes on the way to the payload. The canonical ISBN example 0-306-40615-2 is an ISBN-10; the bars of an ISBN barcode carry the ISBN-13, so the note shows every intermediate number rather than a silent conversion:

Code 39 has no lowercase letters, so a fictional input of shelf-12b becomes SHELF-12B and the note says so: "Code 39 has no lowercase letters — your input was converted to uppercase." Code 128 carries no visible check digit; its note is the code-set analysis the validator performs as advice — for the fictional lot number LOT-2026-0418 it reads: "Uppercase text with digit runs — code set B (or A) for the text, switching to code set C where four or more digits run consecutively." The code-set optimisation inside the symbol itself is the renderer's, following the same rules.

Independent decoding after rendering

An accepted payload is cross-checked once more before it is drawn: its check digit is re-derived with the independent arithmetic and compared with the digit the validator recorded. On 4006381333931 that cross-check passes; a failure here would be a bug rather than a typo, and the barcode would not be shown. Only then is the renderer called — and its output is not taken on trust. The generator rasterises the actual SVG shown on the page and asks ZXing, a decoding engine independent from the renderer, to read those pixels. The preview and download controls remain withheld when the decoder cannot read the image (the engine names this reason decode-failed) or reads a different payload (payload-mismatch, with the text it read quoted in the message).

"A different payload" is judged exactly, with one disclosed family of equivalences: a UPC-A reader may report twelve digits or the equivalent zero-prefixed thirteen, and an EAN-13 that begins with 0 may be reported as the twelve-digit UPC-A without that zero — the same printed symbol either way. Handing the engine's comparison each reading at build time:

• 4006381333931 read as 4006381333931 (the validated payload itself) — accepted as the same symbol.
• 4006381333931 read as 4006381833931 (a fictional misreading) — withheld as a payload mismatch.
• 036000291452 read as 0036000291452 (the zero-prefixed form of a UPC-A) — accepted as the same symbol.
• 9780306406157 read as 0306406152 (the ISBN-10 that was typed) — withheld as a payload mismatch.
• SHELF-12B read as shelf-12b (the Code 39 text as typed) — withheld as a payload mismatch.

The last two are the common surprises. The decoder reports what the bars carry — the converted ISBN-13, the uppercased Code 39 text — and the engine compares that reading with the payload the notes reported, never with your keystrokes. The Barcode Verifier & Scanner exposes the same independent-reader idea for an uploaded image or a camera view, so a downloaded file can be read back on its own.

What each download carries

The downloads are covered separately rather than inherited from the preview. The SVG is released only after the drawing on the page has been decoded, and it is free, with no watermark and no account. PNG export is rendered to its own canvas and decoded again before the file is released. The single-barcode PDF exporter translates the independently decoded SVG's rectangles and caption into native PDF vector geometry rather than embedding a screenshot. Two further exports are text translations rather than images. ZPL requires the full validated payload; for EAN and UPC symbologies the check digit is verified, then stripped before the field data because the printer recomputes it, and the engine says so in its notes. For 4006381333931 the field line is ^FD400638133393^FS and the note reads: "The ^FD data carries only the data digits — the printer recomputes the check digit and arrives at the same 1 for this EAN-13 that our validator already verified." EPS is converted from the generated SVG markup, one SVG pixel to one PostScript point, with the vertical axis flipped because PostScript measures from the bottom edge. On a tiny generated-style sample — a white background and two bars — the engine skips the background and emits 2 fill operations, the first being 4 8 2 20 rectfill, with the warning "Human-readable text uses the printer's Helvetica; bar geometry is exact." ZPL and EPS export explained has the rest.

Bulk PDF label sheets are the deliberate exception, and the methodology says so. Each pasted row — up to 300 lines — receives the same structural and check-digit validation before rendering, but the rows of the assembled PDF are not individually decoded. The sheet geometry is arithmetic too: on the first preset (Avery 5160 — Letter, 2⅝ × 1 in, 30 per sheet), 30 labels fit one sheet, so a fictional list of 100 rows needs 4 sheets. Treat a sheet as validated, not read back, and scan a printed sample.

Where the browser version stops

Three limits, each stated without invented figures. Math, not optics. The checks above cover generated SVG and PNG pixels. Whether a printed symbol scans depends on contrast, size, substrate, and preserved quiet zones, and no browser check can certify ink, substrate, scaling, contrast, or quiet zones after printing, so a physical production sample must still be scanned. Where this site quotes physical figures at all, they come from GS1 member organization size guides linked where used; otherwise the guidance stays qualitative. Symbols, not numbers. Generating an EAN or UPC barcode does not allocate or license the GTIN inside it, and rendering an ISBN barcode does not register an ISBN; whether your product needs a licensed number is answered in Do I need a GS1 barcode? A web page, not an installed application. Processing is local and nothing is sent to a server, but the tool is reached through a browser — which is the whole premise of the demand test above, and why this page does not describe the browser version as an offline production system.

Reading the notes and the errors

• A note beginning "You entered…" names the mode that ran: computed, the check digit was appended for you; verified, you supplied it and it checks out — the only note that says anything about a number you were handed.
• A conversion or uppercase note discloses a normalisation. The bars carry the payload it names, so compare a decoded value with that payload, not with what you typed.
• A "Check digit mismatch" error names the data digits, the digit they require, and the digit you supplied, then offers the data-only route. It is a refusal, never a repair.
• A payload-mismatch or decode-failed message comes from the independent decoder after rendering: the first quotes what it read instead of the validated payload; the second means it could not read the bars and suggests a shorter value or a report through the contact page.
• The closing line on every generator page — test with your own scanner before production — is there because it is true on every page.

Common misreadings

• "Verified" means registered. It means structurally valid and read back; licensing is not checked.
• A decoded preview will scan when printed. That is optics, not math — test the printed result with your own scanner.
• A mismatch means the last digit is wrong. The number as a whole is inconsistent; above, a data-digit typo surfaced as a check-digit mismatch.
• Local processing means an offline product. Nothing is uploaded, but the tool is a web page; the demand test above exists because those are different things.
• A label sheet is verified like a single barcode. Its rows are validated; the assembled PDF is not decoded.

Browser version FAQ

Not sure which side of the line you are on? Read Do you need barcode software?, or use the free online barcode generator first and see whether the browser workflow already covers the job.