How NFC-Powered Devices Work Without a Battery
A Bagtag luggage tag sits in your suitcase for 3 years, updates its e-ink display every time you fly, and never sees a charger. There’s no battery inside. Tap your phone, the screen redraws with your new flight details, done.
The phone is literally powering the tag for the 2 seconds it takes to push a new image, using the same NFC radio you use to pay for coffee. Once you understand the mechanics, a whole class of batteryless IoT products stops looking mysterious and starts looking like a toolkit: smart shelf labels, medical patches, commissioning tags, single-use diagnostics.
This piece walks through how NFC energy harvesting actually works, what you can (and can’t) ship on NFC alone, and when you need to bolt on BLE to get a product that does more than wait for a tap.
The Physics: How NFC Delivers Power
NFC runs at 13.56 MHz. A reader (your phone) drives an antenna coil hard enough to produce an oscillating magnetic field a few centimeters across. A nearby tag has its own coil, tuned as part of an LC circuit to that same 13.56 MHz. The field induces a current in the tag’s coil, a rectifier turns it into DC, and a small cap smooths it out.
PHONE (Reader) TAG (Harvester)
┌──────────────┐ ┌──────────────┐
│ ~13.56MHz │ ))) field │ LC antenna │
│ antenna │ ═════════► │ + rectifier │
│ + driver │ │ → MCU/load │
└──────────────┘ └──────────────┘
ACTIVE PASSIVEHow much power comes out the other side? In practice, 5 to 15 mW at the harvesting pin with a typical phone, falling off fast with distance and misalignment. NXP’s NTAG 5 and ST’s ST25DV datasheets both quote numbers in that ballpark, with the ST25DV rated up to around 6 mW under good coupling. Bench setups with bigger reader antennas can push more, but you should design for phone-grade coupling if consumers are in the loop.
Three standards matter. ISO/IEC 14443 is the high-data-rate proximity standard used for payments and passports, running 106 to 848 kbps within 1 to 4 cm. ISO/IEC 15693 is vicinity coupling, slower but workable out to 10 cm or so. The NFC Forum tag types (2, 4, 5) sit on top of these and define how data is formatted. For harvesting-heavy designs, Type 5 (built on 15693) tends to win on range; Type 4 (on 14443) wins on throughput.
What’s Inside a Batteryless NFC Device
Strip a smart shelf label or an NFC-powered sensor tag and you’ll see roughly the same parts every time:
[Antenna]─[Match]─[NFC IC]─┬─[Harvest Cap]─[LDO]─[MCU]
├─[I2C/SPI]────────────┤
└─[EEPROM] └─[e-ink / sensor]The antenna is usually a printed or etched copper spiral, tuned with a small matching network. It feeds an NFC frontend IC (NXP NTAG 5, ST ST25DV-PWM, or similar) that handles the RF, the protocol stack, and a chunk of EEPROM.
Key pin on these chips: the energy harvesting output. It’s a regulated DC tap off the rectifier, sized for external loads. Hang a reservoir cap on it (often 10 to 100 µF depending on your burst), feed an LDO, and you have a power rail for a microcontroller or peripheral.
The peripheral is where the product gets interesting. An e-ink controller pulls tens of mJ for a single refresh, then holds the image with zero power. A digital temperature sensor draws microamps while sampling. A small Cortex-M0+ can boot, read EEPROM, do some work, and go back to sleep inside the tap window. The NFC IC’s EEPROM acts as a mailbox between the phone and the MCU, so neither side needs the other to be powered at the same instant.
Use Cases That Work On NFC Alone
What ties these together: they all wait for a tap from a human or a reader gate.
NFC e-ink displays. Bagtag is the poster child, and the mechanism is exactly what it looks like. The airline’s app writes a new boarding pass image to the tag’s EEPROM, the tag’s MCU wakes on harvested power, drives the e-ink controller, and the ink locks in place. No battery, no maintenance, years of service life. Retail shelf labels from Pricer and SES-imagotag work on similar physics at scale.
Commissioning and provisioning tags. Tap a phone to a new thermostat or access point to write Wi-Fi credentials into NFC EEPROM, then the main MCU reads them on first boot. This is a common NFC-based provisioning pattern in devices that otherwise have no input surface.
Tap-to-read data loggers. A disposable cold-chain tag with a temperature sensor and a coin cell for logging, but NFC for readout. Some variants skip the cell entirely and only sample when tapped.
Authentication and smart packaging. NFC tags on pharma boxes, spirits bottles, and luxury goods, powered entirely by the verifying phone.
The Limits of Batteryless NFC
The device is dark between taps, and that’s the single biggest constraint that kills a lot of product ideas. No autonomous sensing. No beaconing. No wake-on-motion or alerting.
Range is centimeters. You can’t gate a warehouse door with a batteryless NFC tag on a pallet at 3 meters. ISO 15693 buys you a bit more room than 14443, but it’s still short-range by design.
Power is too thin for a radio. A BLE advertisement might need 5 to 15 mA at 3 V for a few milliseconds. You can do it on harvested NFC if the phone stays put, but it’s fragile. Continuous sensing, bright LEDs, or buzzers are out.
Data rates are modest: 106 kbps is typical for Type 2/5, up to 848 kbps on Type 4. Fine for a boarding pass, painful for a firmware update.
When any of these bite, you add a second radio.
NFC + BLE: The Best-of-Both Architecture
NFC is great at zero-power provisioning, secure out-of-band pairing, and tap UX. BLE is great at range, autonomy, and throughput. Put them on the same board and the weaknesses of each cancel out.
Three patterns show up repeatedly:
NFC for provisioning, BLE for runtime. Tap the phone to pair (no PIN codes, no discovery lists), then BLE carries the actual session. Nordic’s nRF52 and nRF54 families bake this in: the NFC-A tag peripheral lives on the same SoC as the BLE radio, and the pairing handoff is a documented flow. If you’re designing a BLE device at scale, the BLE implementation guide covers the radio side of the same problem.
NFC as a dead-battery fallback. August and Yale smart locks use this: even with a flat battery, you can tap an authorized phone to the lock and the NFC field powers the bolt mechanism or at least the auth check. The coin cell handles normal operation; NFC is the lifeboat.
NFC for display + config, BLE + coin cell for beaconing. Medical patches and asset trackers often run this split. The e-ink label and initial config come from taps. The beacon, the sensor sampling, and the uplink run off a coin cell over BLE.
The cost is real: you add a BLE SoC and a battery, which means a BOM bump of maybe $1 to $3 and a case that has to hold a CR2032. What you get in return is a device that works without a human standing next to it.
A couple of competitors are worth knowing about. Wiliot harvests from ambient RF (cell, Wi-Fi) to run a BLE-adjacent beacon, which trades NFC’s reliable tap power for always-on but very thin ambient power. EnOcean uses kinetic and solar harvesting for switches and building sensors, a different philosophy entirely. Neither replaces NFC for tap-driven UX.
Designing for Energy Harvesting: Practical Tips
Design for the worst phone in your user’s pocket, not the bench rig. Coupling varies 3x or more across phone models depending on antenna location and case thickness.
Size your reservoir cap for the biggest burst you’ll hit. E-ink refreshes can want 20 to 50 mJ in a couple hundred ms. If the cap is too small, the LDO browns out mid-refresh and you get a half-drawn screen.
Pick an MCU with fast boot and µA-range sleep. Cortex-M0+ parts from ST, Nordic, and TI all do this well. Skip anything with a slow crystal startup; you don’t have the milliseconds to spare.
Validate across at least 10 phone models before you ship. I’ve seen designs that worked flawlessly on iPhones and failed silently on certain Samsung models because the NFC antenna sits in a different corner.
Consider ISO 15693 (NFC Forum Type 5) if you need more than 4 cm of range or want to read multiple tags at once. You give up some throughput; you gain real practical range.
Choosing Between NFC-Only and NFC+BLE
Need | NFC only | NFC + BLE
-----------------------------|----------|----------
Tap-to-update display | ✓ | ✓
On-demand sensor read | ✓ | ✓
Autonomous beaconing | ✗ | ✓
Range > 10 cm | ✗ | ✓
Zero battery, zero maint. | ✓ | ✗
OOB pairing + dead-batt read | — | ✓
Firmware updates in field | ✗ | ✓If your product is genuinely event-driven (a label, a boarding pass, a config tag, a disposable), batteryless NFC is a shipping architecture and has been for a decade. If you need the device to do anything while nobody’s looking at it, add BLE. The hybrid path is the pragmatic default for most connected products, and the tooling (Nordic nRF52/54, NXP, TI CC2340) has caught up to make it a short design cycle instead of a research project.
FAQ
Can NFC power a device without a battery? Yes. An NFC reader (typically a phone) generates a 13.56 MHz magnetic field that induces current in the tag’s antenna coil. After rectification, this provides roughly 5 to 15 mW at the chip, enough to run an MCU, refresh an e-ink display, or poll a sensor while the reader is within a few centimeters.
How much power does NFC provide? Practical budgets land at 5 to 15 mW with a phone reader at close range, dropping sharply with distance and antenna misalignment. ST’s ST25DV specs its harvesting output up to around 6 mW; NXP’s NTAG 5 is in a similar range. Dedicated reader hardware with larger antennas can deliver more, but phone-grade coupling is what most consumer products have to plan for.
Can you combine NFC and BLE in one device? Yes, and it’s the dominant architecture for full-featured low-power IoT products. Nordic’s nRF52 and nRF54 series integrate both radios on one SoC. Typical patterns: NFC for tap-to-pair provisioning with BLE handling the runtime session, or NFC as a dead-battery fallback when the coin cell powering BLE runs out.
Hubble Network extends low-power connectivity beyond NFC’s tap range, letting battery-constrained devices reach satellites directly over Bluetooth. See how it works →