Bulk Barcode Labels — CSV to Printable PDF Sheets

Who this is for

Anyone who needs a box of labelled products rather than one barcode at a time: a shop putting shelf labels on stock, a warehouse labelling bins and cartons, a seller preparing products for a marketplace, a library or lab sticking asset codes on equipment. The pattern is always the same — the numbers already live in a spreadsheet, and the job is getting them onto physical labels without paying for yet another subscription: paste the column, pick the sheet, download the PDF. If labels must merge live from a database or drive an industrial printer, compare this workflow with the barcode software decision guide.

Getting a column out of Excel or Sheets

Select the column of barcode numbers (click the column header, or drag over the cells), copy, and paste into the box above — each cell becomes one line. To print a name or SKU under each barcode, select two adjacent columns — values first, text second — and paste both; Excel separates the columns with a tab, which the tool reads automatically. From a CSV file, open it in any editor and paste the relevant lines; a value,text pair per line works the same way. One caution for spreadsheet users: formatting a column of long numbers as Number can make Excel display them in scientific notation and mangle the paste — format barcode columns as Text before you paste values in.

The separator rule is fixed. Each non-blank line is split at its first tab if it has one, otherwise at its first comma; what comes before is the value, everything after is the label text, commas included. Tab wins because a spreadsheet paste is tab-separated and its cells may contain commas. One pair of surrounding double quotes is stripped from either column, and blank lines print nothing but keep their line numbers.

Importing a file instead of pasting

The file import fills the same box. The delimiter follows the extension — .csv comma, .tsv tab, .txt decided by its first non-blank line — and an unclosed quoted field is refused with the reason rather than guessed at. Nor is a header guessed away: a fictional export — a quoted header row, then the two cited EAN-13 numbers with label text, saved as labels.csv — imports as 3 rows (comma-delimited), and the header then fails validation with “A EAN-13 contains digits 0–9 only (spaces and hyphens are ignored).” Imports stop at 300 non-blank rows, and a file over 1 MB is declined before it is read.

Template geometry

The three presets use the manufacturer-published sheet geometry, and the figures below are generated from the same data the PDF placement code uses, so this table cannot drift from what actually prints. Our unit tests verify that each template's margins, labels, and gaps reproduce the page dimensions exactly.

Positions follow from that table by addition: a label's left edge is the side margin plus its column number times the pitch (label width plus column gap), its top edge the top margin plus its row number times the label height, since no preset has a vertical gap. On Avery L7651 the pitch is 40.6 mm, and the last of its 65 cells (column 5, row 13) starts at x = 167.15 mm, y = 265.1 mm, leaving 4.75 mm to the right edge and 10.7 mm to the bottom — the margins the sheet began with.

Go deeper: Label-sheet geometry walks the placement engine through every preset, position and sheet count; the guides hub has the rest.

From a row count to a sheet count

Labels per sheet is columns times rows; sheets needed is the number of labels that will print divided by that, rounded up. The summary reports it as you type. A fictional list of 72 valid rows needs:

• Avery 5160 (30 per sheet): 3 sheets, 12 labels on the last.
• Avery 5163 (10 per sheet): 8 sheets, 2 labels on the last.
• Avery L7651 (65 per sheet): 2 sheets, 7 labels on the last.

The input cap is reported the same way: paste 312 non-blank lines and 300 are kept, and the summary says “Only the first 300 of 312 non-blank lines were processed” — run a longer list in batches.

A custom grid is checked, never clamped

Custom mode takes nine values in millimetres and refuses anything it cannot place. A fictional A4 grid — labels 60 × 30 mm, 3 columns by 8 rows, top margin 15 mm, left margin 10 mm, gaps 5 mm across and 3 mm down — is accepted as “Custom — A4, 60 × 30 mm, 24 per sheet”, using 200 of the page's 210 mm width and 276 of its 297 mm height. Raise the rows to 10 and the same grid is refused in the engine's words: “The grid is 342.0 mm tall but the page is only 297.0 mm — reduce rows, label height, gap, or margin.” The geometry guide explains why nothing is shrunk to fit.

Print at 100% — the one setting that ruins alignment

The PDF places every barcode at exact millimetre positions, but PDF viewers love to "help" by scaling pages. In the print dialog choose Actual size or set scale to 100% — never "Fit to page" or "Shrink to fit", which compress the layout by a few percent and walk every row progressively off its label. Print the first sheet on plain paper and hold it over the label sheet against the light before committing the real stock.

What validation happens before printing

Every row goes through the same engine as this site's single-barcode generators. GTIN-family rows (EAN-13, EAN-8, UPC-A, ITF-14) follow verify-or-compute semantics: enter the data digits and the check digit is computed and appended; enter the full number and the final digit is verified, with a mismatch failing the row — never silently "fixed". Text symbologies (Code 128, Code 39) are checked against their character sets. All of it happens before the accepted payload reaches the renderer. For check digits alone, use the check digit calculator.

That engine on a fictional paste with EAN-13 selected — a cited vector, a blank line, a spreadsheet header, the vector with a wrong check digit, and a tab-separated two-column line — every verdict computed at build time:

Line 2 is absent because blank lines are skipped, not renumbered. On Avery 5160 the summary reads “2 of 4 rows valid, 2 failed. 2 labels → 1 sheet (30 per sheet).” Neither failure is repaired: the corrupted line is told the digit its first twelve require and the digit it carried, and left to you.

One honesty line: a row that passes is structurally valid — right length, right characters, check digit consistent — a property of arithmetic, not a licence. Generating an EAN or UPC barcode does not allocate or license the GTIN inside it (that is GS1's role); see do I need a GS1 barcode?

What the download checks, and what it cannot

Download is a second pass: each accepted row's check digit, where its symbology has one, is recomputed from the normalised payload, and the renderer may still decline to draw a symbol; a row stopped at either point is listed as refused with its line number and the PDF is built from the rest. Nothing reads the bars back. The methodology page is explicit that bulk PDF label sheets are the deliberate exception to the independent decode: each row is validated before rendering, but the assembled PDF rows are not individually decoded. What that decode checks and withholds is the subject of how the verifier decodes what you see; what happens after printing no browser check can certify, which is why the tool asks for one printed sheet to be test-scanned.

Bulk label FAQ

Scope, honestly: this tool validates the mathematics and places barcodes at exact template positions. It cannot verify that your printer is set to 100% scale, that your label stock matches the template you picked, or that your scanner tolerates your print quality — test one sheet before printing hundreds. Everything runs locally in your browser; see the methodology page for how the verification layer is tested.