How to Read and Write RFID Card

How to read and write RFID card data requires a compatible RFID reader-writer, software that supports the card’s chip and protocol, and permission to access the relevant memory. First identify the card, read its accessible data, write only to authorized writable areas, and verify the result with a second read.

What Does Reading and Writing an RFID Card Mean?

Reading an RFID card means retrieving information that the card and reader are configured to exchange. Writing means sending data or a supported command to a writable area of the card. The exact process depends on the chip, frequency, communication protocol, memory layout, and security settings.

These operations are often combined in a single desktop reader-writer, but reading capability does not automatically mean writing capability. A reader may identify a card without supporting memory writes, and a card may allow its identifier to be read while protecting other memory areas.

That distinction matters in practical deployments. A library might read a tag identifier to locate a book record. A warehouse might write a product identifier to a UHF tag before associating it with an inventory database. An NFC application might write a supported data record to a compatible HF tag. All three involve RFID, but the hardware and software requirements are not interchangeable.

Reading, writing, encoding, and registration

Operation	Meaning	Example
Read	Retrieve accessible card or tag data	Read an RFID identifier
Write	Store data in an authorized writable area	Write an inventory reference
Encode	Format data according to an application or standard	Encode a supported EPC value
Register	Link a card or tag to a system record	Associate a tag with a book
Verify	Read back data and check the result	Compare the written value with the intended value

A card can be written successfully yet still fail in the target application. The data may be in the wrong memory location, use the wrong format, or lack a corresponding record in the connected software. Treating the reader’s success message as the entire test can hide these problems until the card reaches the workplace.

Identify the RFID Card Before You Read or Write It

The first task is not to open the software and press Write. It is to determine which technology the card uses and what operations that technology supports.

RFID operates across multiple frequency bands. Cards can look almost identical while using different chips and communication methods. Frequency alone is not enough to establish compatibility.

Low-frequency RFID cards

Low-frequency RFID commonly operates around 125 kHz or 134.2 kHz, depending on the application and technology. It is used in some identification and access-control systems.

Some LF credentials primarily expose a fixed identifier. Others support different configuration or data functions. A compatible reader may be able to detect a card without being able to modify it.

Before attempting to write an LF card, confirm the chip model and the manufacturer’s supported programming method. Do not assume that a generic RFID writer can change a factory-defined identifier.

High-frequency RFID and NFC cards

High-frequency RFID commonly operates at 13.56 MHz. This category includes NFC-compatible tags and other contactless technologies used in identification, ticketing, libraries, and access systems.

The frequency does not determine the complete set of supported operations. Two 13.56 MHz cards may use different protocols, memory layouts, or authentication mechanisms. A reader-writer must support the relevant card family and commands.

For an NFC tag that supports NDEF, for example, a compatible application may write a text record or URL. That is different from writing to a protected sector on a different contactless card. If the card is part of an access-control or payment system, use the authorized issuer’s or administrator’s enrollment procedure.

Ultra-high-frequency RFID cards and tags

Ultra-high-frequency (UHF) RFID is commonly used for item-level inventory, warehouse tracking, logistics, and asset identification. Many passive UHF tags use the EPC Class 1 Gen 2 air interface, standardized internationally as ISO/IEC 18000-63.

A UHF reader-writer may be able to read an Electronic Product Code (EPC) and write to permitted tag memory. However, available operations depend on the tag IC, reader firmware, access settings, and software.

For an inventory workflow, the goal is usually to ensure that a tag carries the expected identifier and that the business application associates it with the correct product or asset. Writing a value is only one step in that process.

What Equipment Do You Need to Read and Write RFID Cards?

A basic setup usually requires four things: a compatible RFID card or tag, a reader-writer, supported software, and a computer or host device. The specific equipment depends on whether the project uses LF, HF/NFC, or UHF technology.

Component	What it does	What to confirm before purchase
RFID card or tag	Stores an identifier or other supported data	Frequency, chip model, memory, and permissions
RFID reader-writer	Communicates with the card	Supported protocols and actual write capability
Programming software	Sends commands and displays results	Chip compatibility, data format, read/write functions
Computer or host	Runs the software or application	USB, serial, Ethernet, SDK, or API requirements
Business application	Uses the card data	Database mapping, enrollment, and validation rules

Choosing a desktop RFID reader-writer

For a desktop encoding workflow, check the device’s supported chip types before comparing read range or output power. A reader-writer intended for UHF inventory tags cannot automatically read or write an HF/NFC card.

Cykeo’s SSD-D1AL desktop RFID tag administration platform is one example of equipment intended for compatible UHF tag management. Its supplied specifications describe a USB-connected platform with a maximum port output of 33 dBm, a reading range within 30 cm, and a writing range within 10 cm. These are product-specific figures, not guaranteed distances for every tag or installation.

For applications such as inventory tagging, the platform’s suitability should be assessed against the required tag protocol, encoding workflow, software integration, and operating environment. If you are working with NFC cards, confirm that the reader supports the relevant NFC technology instead.

What should the software be able to do?

At a minimum, look for the ability to:

• Detect and identify supported cards or tags.
• Read the data that the current user is authorized to access.
• Write to the intended writable memory area.
• Report errors rather than silently accepting failed operations.
• Read back the written data for comparison.
• Export or log results when traceability is required.

For development projects, SDK or API access can be important. A demonstration application may be sufficient for a single-card test, but batch programming or integration with an inventory database often requires additional application logic.

How to Read and Write RFID Card Data: Step-by-Step

The workflow below is a general process for authorized RFID card and tag operations. The exact commands, screens, and memory addresses vary by technology, so use the reader and chip manufacturer’s documentation for the actual procedure.

Step 1: Connect the reader and detect the card

Connect the reader-writer using its supported interface. Install the required driver or application if necessary, then open the vendor’s supported software.

Place one known-compatible test card in the reader’s operating area. Confirm that the software detects it and can retrieve the data it is permitted to read.

If the card is not detected, do not proceed to writing. Check the connection, card positioning, operating mode, and protocol compatibility first.

Step 2: Read the existing data

Read the card’s accessible identifier or memory area and save the result for comparison. Depending on the software, the output may be displayed as hexadecimal values, decimal numbers, text, or a decoded application record.

Do not assume that the displayed value represents the entire card contents. A card may contain multiple memory areas, some of which are protected or unavailable to the current reader.

Step 3: Define the data you need to write

Determine the exact value and format required by the receiving application. For example, an inventory workflow may need a valid EPC identifier, while a compatible NFC tag may be configured with a supported NDEF record.

Check field length, character encoding, byte order, and any standard the application expects. These details matter: the same logical number can have different representations in decimal and hexadecimal, and a value stored in the wrong format may not be recognized by the software.

Step 4: Write only to the intended area

Select the correct writable memory area and follow the manufacturer’s documented write procedure. Use a spare card for initial testing, especially if the operation could affect configuration or access permissions.

Avoid changing passwords, locking memory, or modifying reserved areas unless the task specifically requires it and you have authorization. Some configuration changes can restrict future access or make a tag permanently unusable.

Step 5: Read back and verify

After the write operation, read the card again and compare the returned data with the intended value. Then test it using the application that will consume the data.

For example, a warehouse tag may contain the correct identifier but still be missing from the inventory database. In that case, the write itself may have succeeded, but the complete business workflow has not.

Why Memory Layout Matters

RFID memory is not necessarily one open area where any value can be written. Different chips organize memory differently, and some regions contain identifiers, manufacturer data, configuration information, or security settings.

GS1 explains that RAIN RFID tags can use four logical memory banks: Reserved, EPC, TID, and User. The User bank is optional, while the EPC bank is used for the EPC identifier. This structure is specific to RAIN RFID tags and should not be confused with the memory organization of HF/NFC cards.

For NFC, memory capacity also varies by chip. NXP’s published specifications list 144 bytes of user memory for NTAG213, 504 bytes for NTAG215, and 888 bytes for NTAG216. These figures refer to those particular chips, not to every RFID card. The same product family supports features such as configurable password protection and read-only locking. NXP+1

That is why the chip model should be known before programming begins. A reader can communicate with a card while still lacking permission to change a particular memory area.

How to Read and Write RFID Card: Troubleshooting, Security, and FAQs

Reading and writing RFID cards reliably requires more than a compatible reader. The card must support the intended operation, the software must use the correct data format, and the receiving application must interpret the result correctly. These checks are especially important when preparing cards for inventory, libraries, or access-management systems.

Common RFID Card Reading and Writing Problems

When a card does not behave as expected, avoid changing several settings at once. Start by identifying whether the problem occurs during card detection, reading, writing, or application processing. Each stage points to a different set of possible causes.

Problem	Possible cause	Recommended action
The reader cannot detect the card	Incompatible frequency or protocol, poor positioning, connection issue	Confirm card specifications, reader support, and connection
The card can be read but not written	Protected memory, missing authentication, or unsupported write function	Check the chip documentation and authorized permissions
The written value differs from the intended value	Incorrect data format, byte order, or memory location	Read back the data and compare it field by field
The card works in the demo tool but not in the application	Different data expectations or missing database association	Check application settings, enrollment, and record mapping
Some tags are detected inconsistently	Antenna placement, tag orientation, nearby metal or liquid, or RF interference	Test the tag in its actual mounting and operating environment
A card becomes read-only unexpectedly	A memory lock or configuration setting was changed	Review the chip documentation and test configuration on spare cards

When a reader detects a card but cannot write to it

This is a common source of confusion. Reading and writing are separate capabilities, and access to memory may depend on the card’s security configuration. The reader may correctly identify the card while the write command fails because the selected area is protected or the device does not support the required command.

Check these items in order:

1. Confirm the exact card or chip model.
2. Verify that the reader-writer supports that technology and write operation.
3. Identify the target memory area.
4. Confirm that the operation is permitted and that required authentication is available.
5. Test using a known-compatible spare card and the manufacturer’s supported software.

Do not attempt to bypass protected memory. For credentials managed by an employer, building, or service provider, ask the authorized system administrator to issue or configure the card.

When written data cannot be read correctly

First compare the intended value with the raw value returned by the reader. Look for differences in hexadecimal versus decimal representation, character encoding, byte order, and field length.

Then check whether the application expects data in a particular standard. A correctly written identifier can still be unusable if the application expects another format or if the identifier has not been registered in its database.

For UHF inventory deployments, verify the EPC structure and the memory area being used. GS1’s EPC/RFID resources provide relevant standards and implementation information. For NFC, consult the specific chip’s datasheet and the application’s supported record format.

How to Read and Write RFID Cards in Batches

Batch processing introduces a different challenge: a small error can affect multiple cards before anyone notices. A repeatable procedure should therefore include source-data validation, individual write verification, and a clear way to isolate failures.

Use a controlled batch workflow

• Prepare the data list. Make sure each card has the intended value and any required business record.
• Check for duplicates. Identify repeated values before programming, unless duplication is an intentional part of the design.
• Keep card states separate. Maintain clearly labeled groups for unprocessed, verified, and failed cards.
• Write and read back. Verify the written data instead of relying exclusively on the software’s success message.
• Register the identifier. Where required, associate the card with the correct product, asset, user, or library record.
• Retest failures. Record the cause and follow an approved retry procedure rather than silently repeating the operation.
• Run a final application check. Confirm that the programmed card works in the intended system.

For a small desktop operation, simple trays and a checklist may be sufficient. For a larger deployment, software-enforced duplicate detection and audit logs can reduce reliance on manual handling.

If 196 out of 200 cards pass the first verification, the first-pass rate is 98%. This is an illustrative calculation, not an industry benchmark. The four failed cards should remain in the record even if they pass after a retry.

Tracking first-pass results, final acceptance, and failure reasons can help identify whether a problem comes from the cards, reader configuration, software, or operator workflow. A high final pass rate alone may hide repeated failures and unnecessary rework.

Security Considerations When Reading and Writing RFID Cards

An RFID card’s identifier should not automatically be treated as proof of identity. Depending on the technology, an identifier may be readable by compatible equipment, while access to other memory areas may be restricted by authentication or security settings.

Protect writable memory and configuration settings

Before changing card data, determine whether the operation affects ordinary user memory, application data, access settings, or a permanent lock. The consequences differ by chip.

For example, NXP’s NTAG213/215/216 family provides configurable password protection and locking features. These capabilities are specific to that product family; other RFID technologies have different security models. Consult the relevant datasheet rather than applying one card’s instructions to another.

Recommended precautions include:

• Use test cards before changing configuration on production cards.
• Avoid writing personal or confidential information directly to a tag unless the design requires it.
• Store programming credentials and access keys securely.
• Document changes to memory protection and lock settings.
• Use authorized enrollment and revocation procedures for access-control credentials.
• Verify that the intended application continues to function after any configuration change.

Reading a card is not the same as authenticating a person

A reader may retrieve an identifier without establishing that the person presenting the card is its authorized owner. For systems where unauthorized access could cause harm, use the credential technology and authentication controls approved by the system provider.

For inventory tracking, the priority may instead be reliable identification, database association, and prevention of duplicate records. The right controls depend on the use case. An asset label, a library tag, and a secure access credential should not be assigned the same security assumptions.

Frequently Asked Questions

1. Can I read and write RFID cards with one device?

Yes, if the device supports both reading and writing for the specific card technology. A reader-writer may support one type of UHF tag but not a 13.56 MHz NFC card, for example. Confirm the supported chip families, protocols, and write functions before purchasing equipment.

2. Can a phone read and write every RFID card?

No. Many NFC-enabled phones can interact with supported NFC tags and records, but they do not provide universal support for LF, HF, and UHF technologies. Compatibility also depends on the phone, operating system, application, chip, and security permissions.

3. Why can I read an RFID card but not change its data?

The card may have protected or read-only memory, require authentication, or use a technology that your reader does not support for writing. Some identifiers are fixed or not ordinarily user-writable. Check the chip documentation and use an authorized programming procedure.

4. How do I confirm that RFID data was written correctly?

Read the card again after writing and compare the returned value with the intended data. Then test the card with the target application to confirm that it recognizes the identifier or record. A successful write message alone does not prove that the complete business workflow is correct.

5. How much data can an RFID card store?

Capacity depends on the card’s chip and memory structure. For example, NXP specifies 144 bytes of user memory for NTAG213, 504 bytes for NTAG215, and 888 bytes for NTAG216. Other RFID cards may have different capacities, memory areas, or restrictions.

6. Can I use the same software for UHF and NFC cards?

Not necessarily. UHF and NFC systems use different air interfaces and often require different reader hardware, commands, and data-handling methods. Choose software that explicitly supports the card technology and the intended operation.

7. What is the best way to read and write RFID cards for inventory?

Use compatible tags and a reader-writer, define a consistent identifier format, and verify every write by reading the data back. Link each identifier to the correct inventory record, then test tags on actual products or packaging. For UHF systems using EPC identifiers, follow the relevant GS1 specifications.

Final Checklist Before Deployment

Before putting programmed RFID cards into service, confirm the following:

• The card frequency, chip type, and protocol are known.
• The reader-writer supports the required read and write operations.
• The data format matches the target application.
• The write operation affects the intended memory area only.
• Read-back verification confirms the expected value.
• The application recognizes the card or tag correctly.
• Failed cards and retry attempts are recorded.
• Security settings and any locking operations have been reviewed.
• A sample has been tested in the actual operating environment.

For Cykeo’s business customers, the practical starting point is to define the application before selecting the hardware. A desktop UHF reader-writer may suit inventory-tag encoding, while NFC and access-control projects may require different readers, card technologies, and enrollment procedures.

The core principle behind how to read and write RFID card is straightforward: identify the technology, use compatible equipment, write only what you are authorized to change, and verify the data in the system that will use it. That approach makes RFID programming more reliable, traceable, and easier to troubleshoot.