Character count varies between on-the-fly and submission feedback

Question

I ran across the 30,000 character limit in this answer, and while working to pare my 42,000+ characters down, I found the "on-the-fly" character limit pop-up quite helpful.

However, that pop-up did not do the same count as the submission count.

After having dropped down to about 30,008 characters and making a few last changes, the pop-up went away and I thought I was good to go. I hit "submit" and then it told me I was at (roughly, I don't remember the exact number) 30,250 characters! 250+ characters more than the "on the fly" count.

So the "on-the-fly" count and the "submission" count are not the same.

EDIT with Nathaniel's analysis

Here's the on-the-fly count shown after adding about 300 characters (exceed by one character):

But here's what shows if one character is removed and an attempt to submit (exceed by 289 characters):

Answer 1

Using my favourite "boilerplate" text (Bleak House, starting at Chapter 1), my results are a little different: (1) the 30001 limit on entry; (2) a report of 30535 on submit. For comparison:

But, after 'Post your answer':

My text as entered is on 537 lines. I wonder if it's line breaks that account for (a) both the different outcomes in "analysis" between my numbers and Nathaniel's, and (b) the difference between "entry/on-the-fly" number (not counted) and "submitted" (counted)?

Answer 2

This is speculative, but it didn't fit in a comment so I'm posting it here.

It appears that your post contains some UTF-16 (Unicode) characters. Some databases count length (nvarchar in this case, according to the SEDE schema) in characters and others count it in bytes, so a UTF-16 character would consume two bytes. If the database used by SE is of this type (I don't know if it is) and if the front-end code checking as you type is just counting string length, this could account for the discrepancy -- the client-side validation says "yup, under 30k -- you're good to go" but when it actually gets to the server the database says "whoa, too much" and rejects it.

The as-you-type check can't ask the database as you type; that'd be too expensive. But either the code that does that checking should apply the same rules, meaning it has to check for multi-byte encodings, or the message you get as you type should provide some hint that 30k characters isn't precisely correct.