Accented characters come back wrong after writing
A text record declares which encoding it uses, and a tool writing one while another assumes something different produces mangled accents on reading. The characters are intact on the tag; what is wrong is the agreement about how to interpret them.
The record declares its encoding
A text record carries more than the characters. It also carries an indication of how those characters are encoded, and a language code.
A reader uses that indication to turn bytes back into letters. When the declaration and the reality agree, accents come back exactly as written.
When they disagree, the bytes are intact and the interpretation is wrong, which is why the result is mangled rather than missing.
Characters outside the unaccented Latin range also cost more than one byte each, so accented text takes more room than its character count suggests.
Where it goes wrong
A writing tool that declares one encoding and writes another. The tag is then self contradictory and every reader gets it wrong.
A reading tool that ignores the declaration and assumes a default. The tag is correct and one particular reader displays it badly.
Content pasted from a source in a different encoding, which can arrive at the writing tool already damaged. The tag then faithfully stores characters that were wrong before they got there.
Read the tag with a second tool to tell these apart. If two readers disagree, the tag is fine and one reader is wrong. If both agree it is wrong, the tag holds what was written.
Addresses are a separate case
A web address is not free text. Characters outside the permitted set have to be percent encoded, and an address containing raw accented characters may not work even when it is stored perfectly.
Some tools encode them for you and some do not, which is why an address with an accented path can behave differently depending on what wrote it.
Internationalised domain names have their own conversion, done by the browser rather than by the tag.
The tag stores characters faithfully in all these cases. What varies is whether what was stored was a valid address.
Avoiding it entirely
Use unaccented characters in anything written directly to a tag where the meaning survives it. This is not elegant and it removes a whole class of failure.
Keep accented text on a page rather than on a tag, and write a short address instead. A web page controls its own encoding and displays correctly everywhere.
Test with the actual text on a phone you did not write with, since a writing tool reading back its own output can hide a disagreement.
And check the length after any change to accented content, because those characters cost more than one byte and a message that fitted may stop fitting.
Frequently asked questions
Is the tag storing the wrong characters?
Usually not. The bytes are intact and the interpretation is wrong, which is why the result is mangled rather than blank.
Do accents take more space?
Yes. Characters outside the unaccented Latin range cost more than one byte each, so accented text is larger than its character count.
Why do two apps show it differently?
Because one is honouring the declared encoding and the other is assuming a default. That disagreement is the fault.
Can I put accents in a URL on a tag?
They need to be percent encoded to be valid, and not every tool does that for you. An unaccented path avoids the question.