RF engineering guide
Wooden Card RFID Technology Types
Wooden card RFID technology types decide whether the card works with a hotel lock, door reader, phone, event scanner, loyalty platform, or authentication system. Choose the chip route — LF, HF/NFC, NFC tag, entry-level HF, AES-secured lightweight HF, standard HF, high-security AES HF, UHF, or programmable 125 kHz — from the system requirement, then approve it in the real card body.
Compare every RFID route before choosing the card build.
Start from the real reader, phone, lock, scanner, or data platform. The table keeps chip route, encoding, and approval risk in one place.
| Route | Frequency | Best use | Chip route | Phone fit | Encoding | Approval |
|---|---|---|---|---|---|---|
| LF RFID | 125 kHz | Legacy access control, selected hotel locks, staff ID, and replacement credentials where the existing reader requires LF. | programmable 125 kHz, EM-compatible, or system-specific LF chip selected by reader requirement. | Not phone-readable for normal smartphone NFC use. | Facility code, card number, clone or emulation route, or blank supply depending on the access provider. | Test on the exact door reader, enrollment reader, or lock before production. |
| HF / NFC | 13.56 MHz | Modern access, NFC business cards, loyalty, events, hospitality, member ID, tap-to-profile, and QR plus tap programs. | NFC tag, standard HF, high-security AES HF family, or a platform-required 13.56 MHz chip. | Can be phone-readable when the chip and encoded record are selected for NFC behavior. | NDEF URL, vCard, UID list, access data, member ID, QR or serial matching, and optional locking. | Test on target phones, readers, scanners, or locks in the final wood body. |
| NFC Tag | 13.56 MHz NFC | Public phone tap experiences: business cards, menus, profiles, landing pages, loyalty, product authentication, and event pages. | 144-byte NFC tag, 504-byte NFC tag, or 888-byte NFC tag selected by memory need and data plan. | The clearest route for broad smartphone tap behavior when the card opens a public URL or record. | NDEF URL, short URL, profile, vCard, campaign URL, optional QR fallback, and a write-lock decision. | Confirm tap position, record length, redirect behavior, analytics URL, and QR fallback before artwork approval. |
| Entry-level HF | 13.56 MHz | Event tickets, simple guest credentials, lightweight loyalty, transit-style tickets, and programs that need a lean HF/NFC card route. | Baseline or counter-enabled entry-level HF; the 3DES variant only where an existing platform specifically requires that route. | Can be read by NFC phones when formatted for NFC Forum Type 2 Tag behavior, but it is usually selected around a platform or reader specification. | NDEF, UID reference, one-time or limited-use ticket data, counters, password protection, or a legacy 3DES route by chip and platform. | Confirm the exact entry-level HF generation, memory, authentication method, lock bytes, and reader or app behavior before production. |
| AES-secured HF | 13.56 MHz secure HF | Lightweight secure ticketing, controlled membership, event access, loyalty, and programs needing stronger authentication than basic Type 2 tags. | AES-secured lightweight HF or a platform-specified AES-authenticated lightweight HF chip. | Not a generic tap-to-URL choice by default. Phone behavior depends on the app, NDEF setup, and AES authentication flow. | AES keys, authenticated data pages, counters, UID mapping, access rights, and NDEF or app-specific payloads from the integrator brief. | Define key ownership, personalization responsibility, app or reader support, and sample validation before artwork approval. |
| Standard HF | 13.56 MHz | Membership access, gym and club entry, campus, workplace, hospitality, venue, and compatible access systems. | The exact standard HF chip must match the system. The family name alone is not enough. | Usually selected for readers, not public phone tap. Phone behavior depends on the chip and data model. | UID, memory sectors, access keys, card number, member record, or integrator-defined data. | Confirm chip generation, memory, key handling, and test on the real access reader. |
| High-security AES | 13.56 MHz secure HF | Secure enterprise, campus, premium hotel, club, and multi-application credential programs. | high-security AES HF family selected by integrator requirement, including memory and application structure. | Not chosen for public NFC marketing. It is usually a secure reader credential route. | Application IDs, files, keys, secure personalization, UID exports, cardholder mapping, and box labels. | The integrator must define chip, keys, encoding responsibility, sample validation, and data handoff. |
| UHF RFID | Regional UHF band | Selected long-range identification, EPC-style data, asset flow, event experiments, and product authentication tags. | UHF inlay and antenna construction selected around read range, reader power, orientation, and body limits. | Not smartphone NFC. It needs a UHF reader or scanner. | EPC, TID or UID reference, asset ID, batch ID, or project-specific data. | Test range, orientation, nearby materials, reader power, antenna placement, and the final finish stack. |
| Programmable 125 kHz | 125 kHz LF | Compatibility-driven LF access, hotel, ID, and legacy replacement projects. | programmable 125 kHz LF credential route when the reader or lock specifically needs that behavior. | Not phone-readable. | Blank, encoded, cloned by the buyer, or access-provider format depending on the project rules. | Define who encodes the card, confirm the target format, then test on the real reader. |
| Encoding | Depends on chip route | The production layer that connects physical cards to software, access systems, members, rooms, URLs, or packaging. | Works across NFC tag, standard HF, high-security AES HF, LF, UHF, and other selected chip routes. | Relevant when NFC records, QR fallback, or mobile landing pages are part of the workflow. | UID exports, NDEF records, access data, QR, serials, member names, room zones, box mapping, and CSV reconciliation. | Approve one source file for artwork, data, scan tests, box labels, and the replacement workflow. |
RFID workflow views
Compare the reader, phone, encoding, and antenna route.
Use these views to match LF, HF/NFC, NFC tag, standard HF, entry-level HF, high-security AES HF, UHF, programmable 125 kHz, and encoding to the real reader or platform before choosing wood and finish.




Reader compatibility is the technical brief.
The question is not only which chip can fit inside wood. The real question is which chip, antenna, body thickness, data model, and encoding route passes on the exact reader, lock, phone, scanner, or NFC behavior the buyer already uses.
Phone tap, access, and long-range ID are different decisions.
NFC tag is usually selected for phone-readable public tap experiences. entry-level HF, AES-secured lightweight HF, standard HF, and high-security AES HF are usually selected because a reader platform, ticketing app, or access integrator requires them. LF and programmable 125 kHz are compatibility routes for 125 kHz systems, while UHF is a special test-led route for longer read range or EPC-style identification.
Encoding connects the object to the system.
UID, NDEF, access data, QR, serial numbers, member records, room zones, box labels, and replacement files should be planned together. A wood card batch should leave production with scan-tested cards, matched data, and a clear rule for whether NFC records stay editable or are locked.
Frequently asked questions
Which RFID technology should a wooden card use?
Choose from the system requirement: NFC tag for phone tap experiences, standard or high-security HF families where an access platform requires them, LF or programmable 125 kHz for 125 kHz compatibility, and UHF only when longer read range is genuinely needed.
Are wooden RFID cards compatible with existing readers?
Yes, when the chip family, antenna construction, and body thickness are matched to the reader. A working sample is always tested on the real lock, reader, phone, or scanner before production.
Can wooden cards be encoded before delivery?
Yes. UID lists, NDEF records, access data, QR codes, and serial numbers can be encoded and reconciled against one approved production file, with output files for your CRM or access platform.
Specification
| RF routes | LF 125 kHz, HF 13.56 MHz, NFC, entry-level HF, secure HF, selected UHF |
|---|---|
| Common data | UID, NDEF URL, QR, serial, counters, AES keys, access-system data |
| Testing | Phone, door reader, lock, desktop reader, scanner by use case |
| Approval need | Working sample with final wood body and finish |