Character Count: Why "With Spaces" and "Without Spaces" Never Match

The application field says "1,000 characters max." Your word processor says 980. You paste it into the submission form and it says 1,120 — over the limit. The text never changed, but the number did. Almost always for one reason: the two tools disagree about what counts as a character.

With spaces vs without spaces: same text, different number

The most common gap is whether whitespace counts. A short sentence makes it obvious.

Three spaces, three characters. The problem is that the gap scales with length. In ordinary prose, whitespace is roughly 15–20% of the total character count. On a 1,000-character essay, that's 150–200 characters — an entire paragraph riding on which rule you use.

Line breaks add another wrinkle. A newline is whitespace too, so tools that count "with spaces" often count every Enter as a character. The more paragraph breaks you have, the further the numbers drift apart.

Which rule should you use?

Whoever receives the text decides. In practice:

• Application essays and forms: usually with spaces. Some explicitly say "excluding spaces," so read the wording literally rather than assuming.
• Reports and papers: depends on the institution's format guide, and limits are often given in pages rather than characters.
• Anything you paste into an input box: whatever the system actually truncates is the real rule. Assume the stricter number (typically with spaces).

When in doubt the rule is simple: fit the limit with spaces included, and you will not exceed it under either method. The with-spaces count is always the larger of the two, so staying under it keeps you safe no matter which rule the form applies.

When the limit is in bytes, not characters

SMS gateways and some database fields cap input in bytes, and there a Korean character weighs far more than an English one.

The same "안녕하세요" is 10 bytes in one encoding and 15 in another. Korean text messaging has traditionally counted on the EUC-KR 2-byte basis — roughly 40–45 Korean characters (80–90 bytes) before a message is promoted to a long message (LMS) — while the web and most databases use UTF-8 at 3 bytes. Always confirm the exact ceiling in your provider's documentation.

The takeaway: in some places the question is not "how many characters" but "how many bytes, in which encoding."

Common platform limits

Publishing destinations have their own ceilings. The values people hit most often:

Titles are the strict case. Search results truncate the tail, so putting the key words up front matters more in practice than squeezing under the maximum.

Do it in 30 seconds — the character counter

Instead of counting separately for each rule, read them all on one screen.

• With-spaces and without-spaces counts side by side — an answer ready for whichever rule you're asked about
• Byte count switchable between the 2-byte and 3-byte basis — messaging and web limits in one view
• Words, sentences, paragraphs, lines and estimated reading time, live as you type
• Limit presets (500/1,000-character essays, 280-character posts, 2,200-character captions) that flag an overrun instantly
• Repeated words and duplicate sentences highlighted, which makes it useful for editing too

👉 Open the character counter — paste once and every number appears at the same time.

If you also want to see what changed between drafts, 👉 the text diff checker pairs well with it.

Conclusion

Different counts are not a bug — they are different rules. Three things to remember: ① check which rule the recipient uses (with or without spaces), ② when it's ambiguous, fit the limit with spaces and stay safe either way, and ③ where limits are counted in bytes, confirm the encoding (2-byte or 3-byte) as well. Most last-minute panic edits to squeeze under a limit are avoided by checking the rule before you start writing, not after.