RFID Card and NFC Tag Encoding Service

What pre-encoding covers

Pre-encoding means the chip is programmed to the agreed specification before dispatch. The job must match your readers, software and issuing workflow. The table outlines each chip family and the non-secret information needed to scope the work; agree any production-data or key transfer separately before sharing protected values.

Every chip carries a factory-programmed, read-only UID. For projects that only need serial numbers — access, membership or asset registers — we read the UID of each piece and return a file mapping card number to UID, ready to import into your system, with no writing to the chip at all.

For NFC data, we write NDEF records — a website URL, a vCard, plain text or Wi-Fi credentials — in the NFC Forum NDEF format to NTAG 213, 215 and 216 labels and cards. User memory differs by part: NTAG 213 holds 144 bytes, NTAG 215 holds 504 bytes and NTAG 216 holds 888 bytes, so the chip is matched to the record you need to write rather than the other way round. See the NFC sticker page for the label formats.

MIFARE Classic memory is divided into sectors, each sealed by a sector trailer that holds Key A, the access bits and Key B. We write the sector map you specify — a 1K card has 16 sectors, a 4K card has 40 — with the keys and access conditions your system expects. MIFARE DESFire (EV1, EV2, EV3) instead carries AES-keyed applications and files; where an application and key scheme is agreed in writing, we create the application directory and set file access rights so your credential is cryptographically isolated on the card. Both are covered on the MIFARE Classic and DESFire product pages.

NTAG 424 DNA supports SUN (Secure Unique NFC) messaging: with SDM configured and your AES keys loaded, the tag mirrors a fresh authentication code (CMAC) into its URL on every tap, which your back-end verifies. This is the basis of tap-to-verify brand protection, and it only works with customer-supplied keys and a backend you control — see the NTAG 424 DNA label. For UHF cards and labels we write the EPC memory bank from your EPC list, following the GS1 EPC Tag Data Standard for schemes such as SGTIN-96, which binds your company prefix to a per-item serial. For LF cards, we program EM4305 or T5577 chips to a site-code format from the code list you provide.

Check these options against your system →

What you supply

Start with the chip, a non-secret description of the data format and configuration, and any reference-sample requirements. Agree responsibilities and the handling of production data before arranging the first article.

Data file. Variable data can be mapped from a CSV, Excel or XML file with one row per piece. Use anonymised examples to describe which column maps to which field and the numbering order. Agree how the production file will be transferred before sending live credentials or other protected data. For one fixed public URL on every label, a short specification is enough.

Keys and confidentiality. Describe the required key scheme without disclosing MIFARE sector keys, DESFire application keys, NTAG passwords or NTAG 424 DNA AES keys. Do not send secret values in an enquiry form, ordinary email or artwork file. If the agreed work requires a key handover, first agree the transfer method, authorised recipients, permitted use and retention or deletion terms in writing. If keys must stay within your systems, order blank products and encode them in-house.

Sample card. If you already run cards on a live system and want new stock to match, a working sample card lets us confirm the format we should replicate. We read it, describe the scheme we intend to write back to you, and only proceed once you agree the interpretation in writing.

How the process runs

Encoding follows the same documented path on every order, so a disagreement about byte order, a sector map or lock behaviour surfaces on a first article rather than deep into a production run:

1. Specification sheet. Start with the chip, encoding scheme and anonymised data format. Agree the fields, byte order, sector or application map, and password or irreversible-lock requirements in writing. Any production-data or key handover is arranged separately before protected values are shared.
2. Encoded samples for approval. We encode a small first article and send it for you to read on your own reader, lock or backend. Nothing goes to volume until you approve it.
3. Batch encoding. The full run is encoded against the approved specification, so every piece is written to the same settings the first article proved.
4. Read-verify before dispatch. Every card and tag is read back after encoding to confirm the written data matches the specification; any piece that does not is rejected and replaced before the order ships.
5. Data report. The order is delivered with a report mapping each piece to its UID and encoded values as a CSV, Excel or XML file, ready to import into your system.

When to encode in-house instead

Pre-encoding is not always the right call, and we will say so. Two cases are better handled on your side, and we supply the tools for both.

The first is key custody. If your security policy says the master keys for a DESFire or NTAG 424 DNA scheme must never leave your own systems, keep them there: order blank chips and encode them yourself, so the keys are only ever loaded on equipment you control. The second is small or frequently changing lots — a handful of tags for a trial, or data that changes per event — where sending a specification and waiting on a batch is slower than encoding at your desk.

For either case, a desktop reader/writer does the job. The NFC reader/writer with free SDK programs 13.56 MHz cards and tags — MIFARE, DESFire and NTAG — and the wider RFID readers range covers the encoders and handhelds you would use to read and write in the field. Phones can also write NTAG 21x labels through an app, so for a few NFC tags you may not need dedicated hardware at all.

Quality checks and error handling

The verification step is the point of a dedicated encoding service. Reading every piece back — not a sample — is what stops a mis-encoded card being found at a door, a gate or a help desk instead of on the line. A piece whose written data does not match the specification is rejected and re-encoded or replaced, and the order ships only once the whole batch reads clean.

Where a card is both printed and encoded, the printed number and the chip data are matched and verified on the same piece, so a badge's printed serial equals its encoded record and a UHF card's printed code equals its EPC serial. That match is delivered in the data report as one row per piece. First-article approval and read-verification together are what keep unit one and the last unit identical, which is the assurance secured-credential and asset programmes need before they commit to volume. If you want to see how this works in practice, request encoded samples with your own scheme — a setup fee applies to customised samples, confirmed in the quotation — and read them on your equipment before you order. Standard blank samples through the sample pack are free.

Commercial terms

Encoding is a customisation, because the programming, the data mapping and the first-article check are prepared for your specification alone. Customised or pre-encoded samples therefore carry a setup fee, confirmed before any work starts, whereas standard blank samples are free. The encoding charge for a production order is confirmed in the quotation against your chip, scheme and quantity — there is no blanket figure, because a UID report and a diversified-key DESFire run are not the same job.

Standard blank products have a general two-to-three-week lead time; the schedule for an encoded run — including first-article approval — is confirmed in the quotation for your scheme and quantity, and larger or more complex runs are scheduled individually. We reply within one business day, and quote within one business day of a workable enquiry. The manufacturer page sets out how our factory in Shenzhen handles chip supply, materials, production and inspection for an order, and the FAQ covers the wider commercial policy.