Text Tools — word counter and speed reading

How to use Text

Text tools do a small number of jobs, and knowing which one you need saves most of the trouble. Almost every text task is one of the following. Changing case, spacing or line breaks — cosmetic, reversible, safe.

Counting words or characters — depends on what counts as a word, so check the definition. Finding and replacing — the operation most likely to do more than intended. Converting between encodings — where invisible damage happens if you get it wrong. Stripping formatting — pasting through plain text to remove hidden styling.

What a character actually is

A character on screen and a character in storage are not the same unit. Many characters take multiple bytes. Some visible characters are built from several combined pieces — a letter plus an accent mark, or an emoji assembled from parts. So a "character count" can legitimately give three different answers depending on whether it counts bytes, code points, or what a reader would call letters.

This is why a text field with a 100-character limit can reject a message that looks like 80 characters. It is counting something other than what the reader is counting. Plain text is the only format guaranteed to open in forty years. That is not because it is good, but because there is nothing in it to break.

Invisible content

Text carries things you cannot see, and they cause most of the confusing failures. Trailing spaces at line ends. Non-breaking spaces that look identical to normal ones but do not match a search for a space. Line endings that differ between operating systems. Zero-width characters that occupy no space at all. Curly quotes that arrived from a word processor and are not the straight quotes a program expects.

When text refuses to match something identical to it, the cause is almost always one of these. The way to find it is to look at the bytes rather than the rendering — anything that shows you the actual characters instead of the display of them.

Why plain text keeps winning

Formats with more capability keep being invented and keep going obsolete, while plain text stays readable. The reason is that plain text has almost no structure to become incompatible with. There is no version number, no application that must exist, no specification to fall out of support.

It can be read by any editor on any system. It can be searched, compared and merged by ordinary tools. Its differences between versions are meaningful — you can see exactly what changed. It survives being copied, emailed, pasted and stored without losing anything.

That last property is what makes it the right choice for anything meant to last: notes, configuration, records, drafts. Formatting can be added later. Recovering content from a format nobody can open any more is a much worse problem.

Working with text you did not write

Text arriving from elsewhere is where the edge cases live. It may use a different encoding than you assume, contain line endings from another system, or carry formatting characters from wherever it was copied. The safe sequence is to normalise first, then process: settle the encoding, settle the line endings, strip what should not be there, and only then do the actual work.

Doing it the other way around — processing first and cleaning up afterwards — means the mess propagates into whatever you produce, and finding it later is considerably harder than preventing it now.