TIL: In worst case, "20 UTF-8 bytes" == "1 Hindi character" Going to have to remember that.
[deleted]
The best – but not good – way to limit string length
11–20 of 48 posts
Re: The best – but not good – way to limit string length
#12In the age of unicode (and modern computing in general), all of this is more headache than it's worth. What is actually important is that you limit the size of an HTTP request to your server (perhaps making some exceptions for file upload endpoints). As long as the user's form entries fit within that, let them do what they want.
Re: The best – but not good – way to limit string length
#13Thank you for writing this! It’s something I’ve always wanted a comprehensive guide on, now I have something to point to.
Re: The best – but not good – way to limit string length
#14This doesn't seem to cover truncation, but rather acceptance/rejection. If you are given something with "too many" codepoints, but need to use it anyways it seems like it would make sense to truncate it on a grapheme cluster boundary.
Re: The best – but not good – way to limit string length
#15> The byte size allowed would need to be about 100x the length limit. That’s… kind of a lot? Would it need to be, though? ~10x ought to be enough for any realistic string that wasn't especially crafted to be annoying.
They show a single Hindi character that is 15 bytes in UTF-8. That's enough over 10 that it would be believable that Hindi words could get uncomfortably close to the 10x limit.
Re: The best – but not good – way to limit string length
#16> The byte size allowed would need to be about 100x the length limit. That’s… kind of a lot? Would it need to be, though? ~10x ought to be enough for any realistic string that wasn't especially crafted to be annoying.
They show a single Hindi character that is 15 bytes in UTF-8. That's enough over 10 that it would be believable that Hindi words could get uncomfortably close to the 10x limit.
A single hindi character, yes. But they also mention that only ~25% of hindi characters use combining marks.
Re: The best – but not good – way to limit string length
#17This doesn't seem to cover truncation, but rather acceptance/rejection. If you are given something with "too many" codepoints, but need to use it anyways it seems like it would make sense to truncate it on a grapheme cluster boundary.
I don't get into truncation much, but I do mention the risk of:
a) failing to truncate on a code point sequence boundary (a bug React Native iOS used to have)[1], and
b) failing to truncate on a grapheme cluster boundary (a bug React Native Android seems to still have)[2]
[1]: https://adam-p.ca/blog/2025/04/string-length/#utf-16-code-un...
[2]: https://adam-p.ca/blog/2025/04/string-length/#unicode-code-p...
Re: The best – but not good – way to limit string length
#18> The byte size allowed would need to be about 100x the length limit. That’s… kind of a lot? Would it need to be, though? ~10x ought to be enough for any realistic string that wasn't especially crafted to be annoying.
Valid question, and I think you're right in the abstract and most of the time. But I also think you end up with a mismatch.
What's the concrete spec for the limit if you've only got 10x storage per grapheme cluster?
Probably you end providing the limit in bytes. That's fine, but it's no longer the "hybrid counting" thing anymore.
Re: The best – but not good – way to limit string length
#19In the age of unicode (and modern computing in general), all of this is more headache than it's worth. What is actually important is that you limit the size of an HTTP request to your server (perhaps making some exceptions for file upload endpoints). As long as the user's form entries fit within that, let them do what they want.
If you can get away with that, that's great. But I feel like there are still plenty of cases where you want to limit the lengths of particular fields (and communicate to the user which lengths were exceeded).
Re: The best – but not good – way to limit string length
#20Note that normalization involves rearranging combining characters of different combining classes: > Array.from("\u{10FFff}\u0300\u0327".normalize('NFC')).map(x=>x.codePointAt().toString(16)) [ '10ffff', '327', '300' ] If a precombined character exists, the relevant accent will be pulled into the base regardless of where it is in the sequence. Note also that normalization can change the visual length (see below) under…
> The article is somewhat wrong when it says Unicode may "change character normalization rules"; new combining characters may be added (which affects the class sort above) but new precombined ones cannot.
That's fair. I updated the wording in the post.
Thanks for the display info. It's cool and horrible and out of scope for my post.