Text tools

Writing for the web means writing to limits. A meta description that runs past roughly 160 characters gets truncated in search results, a title past about 60 characters does the same, and an ad headline or a social post has a hard cap. Counting by eye does not work, and counting in a word processor gives you the wrong number because it disagrees about what a character is.

Use the word counter for those limits and for reading-time estimates. Use case conversion when text has to move between contexts that disagree about capitalisation — a database column in snake_case becoming a label in Title Case, a heading being reused as a slug. Use the diff when two versions of a document exist and nobody remembers what changed: eyeballing two paragraphs side by side reliably misses a changed number, and that is exactly the kind of edit that matters.

Why character counts disagree

Ask three programs how long a string is and you can get three answers. A word processor counts what it displays. JavaScript counts UTF-16 code units, so a flag emoji is four and most other emoji are two. A database column limit may be in bytes, where the same emoji is four and an accented letter is two. The word counter here counts the way JavaScript and most web forms do, which is what you want when the limit you are writing to is enforced by a browser or a CMS — and it reports characters both with and without spaces, because validation rules differ on that too. When a limit rejects text the counter says fits, the limit is almost certainly in bytes.

Word counts have the same problem in a milder form. Hyphenated compounds, numbers with separators and text in languages that do not use spaces all break a simple split-on-whitespace, and different tools make different choices. Reading-time estimates layer a further assumption on top — a fixed words-per-minute figure for adult prose — so treat that figure as a label for the reader, not a measurement.

Case conversion is about conventions, not capital letters

Turning text into camelCase, snake_case, kebab-case or Title Case is easy for one word and full of edge cases after that. Acronyms are the classic one — is the camel form of "parse HTTP response" parseHTTPResponse or parseHttpResponse? Both are common, codebases pick one, and the converter picks the second because it round-trips cleanly back into words. Going the other way it keeps acronym runs intact, so parseHTTPResponse splits into "parse", "HTTP", "response" rather than one letter per word. Title Case has its own rules about which small words stay lowercase, and no two style guides agree on the list; the converter follows the AP convention of lowercasing short articles, conjunctions and prepositions unless they open or close the title.

The programmer cases — camel, Pascal, snake, kebab, constant and dot — all start from the same split, so converting between any two of them is lossless as long as the words themselves survive. What none of them do is transliterate: an accented letter stays accented, and punctuation other than the separators is kept. If the target is a URL slug, run kebab-case first and then check what is left by hand.

Reading a diff

The text diff compares two pieces of text and highlights what was inserted and what was removed, at line level for structure and at word level within changed lines. It is at its most useful on text that looks identical — two copies of a contract clause, a config file before and after a deploy, the copy a client approved and the copy that went live — where the difference is a single number or word that no amount of side-by-side reading would have surfaced. Whitespace-only changes can be hidden, because a re-indented paragraph is not a rewrite.

All three tools work on text you paste in, in your own browser, which makes them safe for drafts and client material that should not be sitting in someone else's logs.