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 NTAG424, NTAG213 and NTAG215.
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 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.
NFC tags should be used as an identifier which means that they are a link to data rather than a data store themselves. Unless you think your tags may be scanned in locations without internet access, then it's generally a bad thing to store data on the tag itself. Which means that using an NTAG216 or NTAG215 is not a good thing.
Secondly, there have been reports of user problems writing to and, in some cases, reading from larger memory NFC tags. Unless you know your hardware or phones and know the environment in which you will use the tag, Seritag strongly advise testing very carefully before rolling out an NTAG216 project.
Thirdly, they are more expensive.
NTAG215 and NTAG216 chips do not scan or perform better than NTAG213 chips. The difference is simply memory capacity.
The normal reason we get asked to supply NTAG215 or NTAG216 chips is because customers are looking to store contact data or vCard data directly onto the chips. In short, don't do this. Some mobile phones won't be able to rad the data at all and others can mix it up.
The solution is either use a vCard generator (such as https://vcardmaker.com/) to create a vCard file (.vcf) and store this somewhere public on the internet - on your website or similar. Then encode the link to that onto your NTAG213 NFC tag. This also means you can update the vcf file whenever you like without having to re-encode the NFC tags.
Or, use a link/contact sharing webpage. There's a huge selection on the market now but we currently like Bio Sites from Squarespace which (at the time of writing) is free.
This can sometimes be the case if you are encoding a very long link, perhaps a Google Analytics link or similar.
In these cases, you need to use a URL shortener such as Bit.ly to reduce the length of your link or our Ixkio NFC tag management platform.