Use our memory calculator to find which NFC chips you can use for your application. We’ve included here the most popular NXP chips – the NTAG210 (which includes the NTAG210micro), the NTAG212, NTAG213 and NTAG216.
Each NFC chip’s memory is divided into two sections – user memory and system memory. So, while an NTAG210 has 80 bytes of memory, only 48 bytes of memory is actually available to be encoded. To keep things simple, consider a byte as a character such as a letter or number.
From that 48 bytes of user memory, there’s also some additional data that gets included with your data. This is so that NFC readers can understand what type of data you are storing, for example a web address or text. This equates to 8 bytes of data in the base of a web address. Which leaves you being able to store 40 characters only. The good news is that in the case of a web address, the ‘http://’, ‘https://’, ‘http://www.’, or ‘https://www.’ part of your web link is included in that 8 bytes, so you don’t lose any memory space describing your connection type.
The 8 Bytes
The 8 bytes consists of two parts. The entire user data is called an NDEF message. The NDEF message can contain one or more NDEF records, such as a web link. In most encoding situations, there will be just the one NDEF record. Three bytes are used to define the NDEF message, it’s length and the end of the whole message. The other five bytes define the NDEF record including it’s type (such as a URI), the URI identifier (such as ‘http://’) and the length of the type and payload (your data).
It’s also possible to store a web address with a ‘blank’ URI identifier instead of, say, ‘http://’. This would mean that you would need to include the entire web link in your data. It would make no difference to an NFC Forum compatible reading device (all mobile phones for example), but would take up more memory space as the ‘http://’ would require 7 bytes. The length of the data wrapper (the 8 bytes) would not change. In other words, it’s not really worth doing.