I have a text input which restricts input of characters when a certain byte limit has been met. I want to indicate this using a character counter which increases or fills up (in case of a progress bar or circle).

If the text input had a character based limit, this would have been straightforward. But a byte limit makes it tricky.

Should I assume a worst case scenario and set a max byte for each character (eg. 4 bytes) and then calculate the number of characters remaining? Or is there a better way to present this?

  • The immediate thing that springs to mind - what on earth is the use case for this? May 1, 2019 at 8:52
  • @DarrylGodden it's a limit imposed by the API being used. Any changes to the API is out of the question. May 1, 2019 at 8:55
  • I assume UTF-8 character encoding, hence variable char-to-byte length mapping. My advice would be don't make the user guilty of your underlying data structures. Perhaps you can provide us with some more details so we can give you more suitable advice.
    – Mike
    May 1, 2019 at 9:00

1 Answer 1


Given the constraint you've shared I see two possibilities:

  • assume worst case scenario, as you suggested. The questions to consider are:
    • what is the byte limit in the API anyway and what is the most typical length of the message, i.e. how likely are the users to hit the limit?
    • how many users will be affected by this? I.e. if most of your users are typing in e.g. Japanese, Chinese, Cyrillic or other "byte-hungry" character set, the assumption is correct
    • how often do the characters with more bytes encoding appear, i.e. how much of the precious storage space will be lost

In this scenario the users meet with a no-brainer counter that decreases each time they type one character. They may be, however, disappointed by the insufficient length of the message.

  • make the counter dynamic, i.e. the counter presents the amount of bytes available and decreases according to the entered character, which is by one to four units at a time. The questions to consider are:
    • how aware are your users of using variable width encoding and how many of them are there, i.e. who will see the counter decreasing at double, triple or quadruple speed while typing?
    • how likely the more-byte-characters are to appear causing the counter to jump by couple of units while entering just one character

In this scenario you benefit from using variable width encoding, however the users face the consequences. If your users are forgiving you may put some explanation next to the counter, e.g. in the form of a pop-up message that will appear each time a more-byte-character is entered (and allow the users to dismiss it once they are aware).

The advantage of either solution is that users can complain in any case (message limit too strict or counter jumping). Should the complaints be frequent you can use them as a reason for API change request.


You can also combine both of the solutions and the proposed bar/pie display in the following way (your limit is 400 bytes which is something between 100 and 400 characters, depending on what kind of characters the users are typing):

  • show a bar/pie titled space left and decrease it by 0.25% each time the user enters a byte (i.e. one-byte character => 0.25% decrease, four-byte character => 1% decrease)
  • when the bar is between 100% and 25% make it green
  • when the bar is between 25% and 10% make it orange/yellow
  • when the bar is less than 10% (40 bytes, 10 to 40 characters) here is where the worst-case scenario begins - decrease the bar/pie by 1% regardless of the character-byte length and show the message X characters left.

This way you waste not more than 30 bytes space (7.5%, I hope you can afford it).
The users are shown the approximate space left when there is still plenty of it and an exact value left when they reach the limit.
The jumping of the approximate counter will not be noticeable and the jumping of the accurate counter (sub-10%) does not occur.
You can play with the percentage ranges to achieve eye pleasing result.

  • Thanks for the answer, I have already considered some of the questions. To answer your question on the actual byte limit, it is 400 bytes. The average number of characters submitted via the text input is 150. I am afraid that users are going to complain either way and was looking to find a middle ground. I was thinking of using progress bar/circle instead of a counter (like on the Twitter Android app) which would make the counter jumping less obvious, but I'm not sure how effective it would be in lowering the number of complaints May 1, 2019 at 11:37
  • With the information in your comment I've just came up with another solution, see the edit to the answer.
    – Mike
    May 1, 2019 at 20:11
  • Thanks for your answer. Can you explain why we decrease the bar/pie by 1% when it's below 10%? May 2, 2019 at 3:22
  • I thought I have explained it, it must have happend in my dreams, please accept my apology. The answer is extended. By the way, 1% is 4 bytes in your case, thus one largest character. I hope it is clear to you now.
    – Mike
    May 2, 2019 at 8:43
  • Yes. It is. Accepted your answer as well. Thanks a lot! May 2, 2019 at 9:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.