Magstripe Track Format: Tracks 1, 2 and 3 Explained

Magstripe Track Format: Tracks 1, 2 and 3 Explained

Posted by Caymil Printing on Nov 1st 2026

Magstripe Track Format: Tracks 1, 2 and 3 Explained

Magstripe parking ticket beside lane reader

A magstripe track format is the layout of data on one of the lanes running along a magnetic stripe: how many bits per inch, how many bits per character, which characters are allowed and how many fit. Under the ISO conventions used for payment cards, Track 1 holds up to 79 alphanumeric characters, Track 2 holds up to 40 numeric characters, and Track 3 is rarely used. For parking operators, the practical question is different: which layout your gate, pay station or ticket reader expects. That answer comes from your equipment specification, not from the card standard alone.

Caymil
Match Tickets to Your Parking System
Caymil supplies magnetic stripe parking tickets compatible with major parking systems, with custom printing options for operator requirements.
Explore ticket options

TL;DR

  • A stripe is divided into up to three tracks. Each track has its own density, character set and capacity, and a reader decodes them separately.
  • Track 1 is the alphanumeric track (79 characters). Track 2 is numeric only (40 characters). Track 3 is seldom present on payment cards.
  • Every track is framed by a start sentinel, an end sentinel and an LRC check character, so a reader knows where data starts, ends and whether it read correctly.
  • Parking tickets often use the same physical stripe technology but a custom data layout. Confirm the exact format with your parking system’s specification before printing.
  • Order a sample run and test it on every lane device before committing to a large quantity.

Table of Contents

What a track format describes

A magnetic stripe is a single band of magnetic material, and the tracks are defined by where they sit on it. One technical write-up describes the stripe as magnetically homogeneous, with the three tracks defined only by their location. In other words, nothing physical separates the lanes. The read head position and the encoding rules do.

Per a technical document filed with the U.S. Patent and Trademark Office, data is stored in three tracks that run along the stripe, and each track carries different types and amounts of data with different formatting. A “track format” is therefore a bundle of rules:

  • recording density, in bits per inch
  • bits per character, including the parity bit
  • the allowed character set
  • the maximum number of characters, control characters included
  • the framing characters that mark the start and end of data

If any of these differ between the device that encodes the stripe and the device that reads it, the read fails or returns garbage. That is why format questions matter more than the stripe itself.

Track 1, Track 2 and Track 3 compared

The conventional financial-card formats are Track 1 (IATA), Track 2 (ABA) and Track 3 (THRIFT), as laid out in MagTek’s magnetic stripe card standards table, which sits under the ISO 7810, 7811 and 7813 family of standards. That table lists density in bits per inch.

Feature Track 1 (IATA) Track 2 (ABA) Track 3 (THRIFT)
Bits per character 7 5 Rarely used on payment cards
Density 210 bits per inch 75 bits per inch Typically 210 bits per inch
Character set Alphanumeric Numeric Varies by application
Maximum length 79 characters 40 characters Varies by application
Typical use Name and account data Account data for fast processing Seldom present

The Track 1 and Track 2 figures (7 bits at 210 bits per inch with 79 alphanumeric characters, and 5 bits at 75 bits per inch with 40 numeric characters) come from the MagTek standards table. The counts include control characters, so the usable data is shorter than the headline number. The density for Tracks 1 and 3 versus Track 2 is also stated in a magstripe basics guide, which adds that Track 1 is the only financial-card track that may contain alphabetic text.

Why two tracks usually matter more than three

Authorize.net explains that only Track 1 and Track 2 are actively used in payment processing, and that Track 3 is rarely used and may not be present on a card. It also notes that most readers can read both Track 1 and Track 2, which gives redundancy if one track becomes unreadable.

That redundancy idea is useful beyond payments. If your ticket needs to survive wear in a pocket, a sun-baked dashboard or a busy lane, encoding the same essential identifier in a track that your reader treats as primary is a sensible design choice, provided your equipment supports it.

How data is framed on a track

A track is not just a string of characters. Several structural elements wrap the data:

  • Clocking zeros. Per Silicon Labs application note AN148, tracks begin and end with clocking zeros so the reader can synchronize with the self-clocking signal.
  • Start sentinel and end sentinel. The same note describes unique characters that signal where the data begins and ends.
  • Field separators. Within the data, a separator character divides fields such as name and account number, so the reader or host software can split them.
  • Parity. Each character carries a parity bit, which lets the reader catch a single-bit error in any one character.
  • LRC. The longitudinal redundancy check follows the end sentinel. According to AN148, it is the XOR result of all track characters, including both sentinels but excluding the LRC itself.

Parity checks each character. The LRC checks the whole track. Together they are why a good reader rejects a bad swipe instead of passing along wrong data.

When you count capacity, remember that the start sentinel, end sentinel and LRC use up character positions. A 79-character limit on Track 1 does not mean 79 characters of your own data.

Physical encoding versus logical format

Two layers are easy to confuse.

The physical layer is how bits are written on the stripe. The technical filing cited above explains that data is encoded using iron particles in a plastic film, aligned north-south or south-north, and that bits are represented by F2F (Aiken Biphase) flux reversals. A reader senses the timing of those reversals to tell ones from zeros. Because the signal is self-clocking, swipe speed matters less than you might expect.

The logical layer is how those bits are interpreted as characters: the parity scheme, the sentinels, the character table and the field structure. Two tickets can share the same physical encoding and still have different logical formats, which is why a ticket that reads on one device can fail on another.

Physical and logical layers of magstripe data

In practice, this means a working sample needs to pass two tests: the reader must see clean flux transitions, and the host must receive data it can parse.

ANSI and ISO standards: where they apply

The track layouts above come from the ISO card standards family. ANSI identifies ISO/IEC 7811-2:2018 as the low-coercivity magnetic stripe standard and ISO/IEC 7811-6:2018 as the high-coercivity standard. The high-coercivity standard specifies stripe characteristics, the encoding technique and the coded character sets.

Coercivity describes how strongly the stripe resists being erased or altered. High-coercivity media is harder to wipe accidentally, which suits cards that are reused for years. Many disposable or short-life tickets use different media, and the right choice depends on how long a ticket has to hold its data.

The standards were written for financial cards, but the technology moved on. The Scientific Working Group on Digital Evidence notes that the ability to reformat track content has let magstripe technology spread into access control and driver’s licenses. The same flexibility is why parking systems can define their own data layouts on a standard physical stripe.

Which format should a parking ticket use?

There is no single answer, and no one standard dictates it for U.S. parking. A parking ticket is read by a specific lane device, pay-on-foot station or exit gate. That equipment decides:

  • which track the reader reads
  • how many characters it expects, and in what field order
  • whether it expects a financial-style layout or a proprietary one
  • the ticket stock thickness, stripe position and stripe coercivity it can handle
  • how it validates the check character

So the right method is to work backward from the equipment. Ask your system vendor or integrator for the ticket specification, then give that document to your printer. Our own encoding checklist for magstripe parking tickets walks through what to confirm before a run, and our guide to SKIDATA ticket media types covers why media differences matter in testing. If your equipment uses Scheidt & Bachmann ticket specifications, the procurement points there apply to feeder capacity and stock thickness.

What to put in the spec you send a printer

  1. Equipment make and model, including firmware generation if the vendor distinguishes it.
  2. Track used and format, with the character set, field layout, sentinels and any check characters.
  3. Starting number and sequence rules, if tickets are numbered or encoded sequentially.
  4. Stripe type, including coercivity and position relative to the ticket edge.
  5. Stock and size, including thickness range, notches or sensor marks.
  6. Print content, such as logos, rate information, barcode and human-readable numbers.
  7. Quantity and release schedule, since large orders benefit from a pilot first.

Test before you commit

A short pilot catches nearly everything. Run a small batch and put it through every device type you own: entry lanes, exit lanes, handheld units, validators and any backup reader. Check at different swipe or insertion speeds, with tickets from the start, middle and end of the batch. Bend a few lightly and leave some in a warm vehicle, since real tickets live that way. Only then release the full quantity.

Test before you commit

If your site also uses barcodes, remember that a barcode and a magstripe can back each other up. Our guides on parking barcode formats and on Code 128 versus Code 39 help you decide which symbology suits your readers.

Our perspective

Most format problems we see are not about the standard. They are about assumptions. An operator assumes the new tickets will behave like the old ones, and no one checks the track, the field order or the stripe type until a lane starts rejecting tickets.

Since 1937, we have printed tickets for parking and hospitality operations, and our approach is simple: start from the equipment specification, confirm it in writing, and prove it with a sample. Our products are built to work with the major parking systems, including SKIDATA, Amano, TIBA, FLASH Parking, Scheidt & Bachmann and Flowbird, and we offer both stock and custom formats so operators do not have to redesign their workflow around the ticket.

Magstripe stock in particular rewards a specialist. Sequential numbering, encoding, stock thickness and finishing all have to line up. A manufacturer that handles all of those under one roof reduces the number of places a mismatch can hide. That is the reason we keep stocked magstripe tickets on hand and why we are glad to talk through a spec before a custom run.

Richard

Stocked magstripe options for common systems

If your equipment already matches a stocked format, you can skip the custom run. We carry stocked magstripe parking tickets, such as the SKIDATA TKC450 magnetic stripe tickets and Data Park magstripe tickets, and our team can help you match a stock item or design a custom one to your system’s specification.

For machine-issued formats, see our machine-issued valet tickets and dispenser and spitter tickets. For manual valet operations, barcoded valet tickets add scan-ready tracking to a carbonless set.

Caymil

Need tickets encoded to a specific format? Browse our full range on caymil.com or send us your equipment specification, and we will help you match it to a stock or custom ticket.

Common format mistakes to avoid

  • Assuming the card standard applies. ISO financial layouts are a starting point. Parking equipment may expect something else.
  • Forgetting control characters in the count. Sentinels and the LRC take space inside the character limit.
  • Mixing numeric and alphanumeric data. Track 2 style encoding is numeric only, so letters need a track and character set that support them.
  • Skipping the pilot run. A format that passes on a bench reader can still fail on an aging lane unit.
  • Changing stock without retesting. Thickness and stripe position affect reads even when the data is identical.
  • Not documenting the spec. When staff change, a written specification saves you from rediscovering requirements the hard way.

FAQ

What is the difference between Track 1 and Track 2?

Track 1 is recorded at 210 bits per inch with 7 bits per character and holds up to 79 alphanumeric characters. Track 2 is recorded at 75 bits per inch with 5 bits per character and holds up to 40 numeric characters, according to MagTek’s standards table. Track 1 can carry letters, while Track 2 carries digits only.

Do parking tickets use Track 1, Track 2 or Track 3?

It depends on the parking system. The equipment manufacturer defines which track the reader uses and how the data is laid out. Ask your vendor for the ticket specification and share it with your printer before ordering.

What is an LRC on a magstripe?

The LRC is a check character that follows the end sentinel. It is the XOR of all track characters, sentinels included and the LRC itself excluded, as described in Silicon Labs AN148. A reader uses it to confirm the track was read correctly.

Is Track 3 still used?

Rarely for payments. Authorize.net notes that Track 3 is rarely used and may not be present on a card. Other applications can still define their own use of it, so check your equipment’s specification.

Should I order a sample before a large run?

Yes. Test a small batch on every device that will read the ticket, including exit lanes and handhelds, before releasing the full quantity. It is the quickest way to catch a track, stock or stripe mismatch.

Sources