Magnetic stripe cards for developers: tracks, HiCo vs LoCo, and the data file the printer needs - DEV Community

DEV Community

Allan Hall
Allan Hall

Posted on

Magnetic stripe cards for developers: tracks, HiCo vs LoCo, and the data file the printer needs

If your app has to issue swipe cards for an existing reader (a gym door, a loyalty terminal, a library system), most of the work is not the artwork. It is getting the encoded data right so the reader accepts it on the first test card. These are the parts I see developers ask about most.

The three tracks

A standard ID-1 card stripe (the same 85.60 x 53.98 mm size as a bank card) has up to three tracks, defined in ISO/IEC 7811 and 7813:

Track Density Character set Max characters
1 210 bpi Alphanumeric (6-bit) 79
2 75 bpi Numeric (4-bit) 40
3 210 bpi Numeric (4-bit) 107

Most membership, loyalty and access systems only read track 2. Check what your reader actually reads before you plan data for all three.

Each track starts and ends with sentinels. On track 1 that is % at the start and ? at the end. On track 2 it is ; and ?. Fields inside a track are separated by ^ on track 1 and = on track 2. An LRC check character follows the end sentinel. Encoding software usually adds the sentinels and LRC for you, so ask whether your data file should include them or not. Sending them twice is a common cause of failed test cards.

A typical track 2 string for a member card might be just:

;1000234567?
Enter fullscreen mode Exit fullscreen mode

HiCo or LoCo

This is about how hard the stripe is to erase, not how much data it holds.

  • LoCo (low coercivity, about 300 Oe) is cheaper and fine for short-life cards such as hotel keys, but a phone magnet or a bag clasp can wipe it.
  • HiCo (high coercivity, about 2750 to 4000 Oe) resists accidental erasing and suits cards people carry for months or years.

Most readers read both. The encoder is the limit: a LoCo-only encoder cannot write HiCo stripes. If the system provider does not specify, HiCo is the safer choice for anything long-lived.

The data file

Treat the encoding file as production data, not a spreadsheet someone tidies by hand.

  • Keep one row per card and one clearly named column per field (printed_number, track2, name).
  • Store numbers as text. Excel will strip leading zeros from 0012345 and turn long numbers into 1.23E+15.
  • Generate the printed number, any barcode value and the track data from the same source record so they always match.
  • Check for duplicates and blank rows before you send it.
  • Agree with the printer whether the file order is the card order.

There is a longer checklist for numbered and encoded runs on the variable data card printing page.

Artwork around the stripe

The stripe sits on the back of the card along the long top edge, as a band roughly 12.7 mm tall for a three-track stripe. Keep text, signatures and barcodes out of that band, and leave a little clearance either side. If you also print a barcode or QR code, keep it on a plain high-contrast background away from the stripe.

The barcode, numbering and magnetic stripe guide covers when a printed number, barcode or stripe is the better fit, and the free card artwork checker lets you check bleed and safe margins on your file before it goes to print.

Test before the full run

Ask for a small number of encoded sample cards and swipe them on the real reader, with the real software, before approving the run. Check:

  1. The reader accepts the card at all (track and coercivity).
  2. The number the software shows matches the number printed on the card.
  3. Leading zeros survived.
  4. A second card from a different row of the file also reads correctly.

That last check catches a shifted or sorted file, which is easy to miss when you only test the first row.


I'm Allan Hall at PlasticCard.nz, a New Zealand plastic card supplier. Corrections and questions are welcome in the comments.

Top comments (0)