A field guide from TextHive
TextHive is a small browser workbench for text chores that interrupt real writing and debugging: counting, casing, JSON formatting, URL component encoding, and Base64. Each tool is a narrow contract. If you know what the contract keeps and what it throws away, you will trust the output for the right reasons—and distrust it for the right reasons too.
Decide what should stay the same
Before you transform text, name the property you care about. Whitespace? Letter case? Byte representation? Key order? A JSON formatter preserves parsed values for ordinary valid JSON but does not preserve the original spacing or comments (JSON has none). Case conversion changes letters and may alter acronyms. A text counter counts whitespace-separated tokens, not linguistic words in every language. Write the invariant down when the output will replace a source file.
How word counting actually behaves
TextHive splits on whitespace after trimming the ends. Punctuation glued to a word usually stays in that token. Unspaced Chinese, Japanese, or Korean paragraphs often register as one word even when they contain many characters; use the code-point count for those drafts. Reading time divides word count by about 200 words per minute—fine for a rough English estimate, weak for dense code or tables.
Encoding is not protection
URL component encoding makes reserved characters safe to place inside a URL part. Base64 represents UTF-8 bytes with a limited alphabet. Neither encrypts, authenticates, or authorizes. Anyone who knows the scheme can reverse it. Never publish an API key merely because it is Base64 or percent-encoded. Never execute decoded payload text from an untrusted sender; inspect it as data only.
Use a component encoder carefully
A complete URL contains separators with structural meaning: slashes, question marks, ampersands, hashes. Encoding the entire URL with a component encoder turns those separators into inert data. Encode values, then assemble with a URL library. When decoding, remember that a literal plus sign may mean plus—not space—unlike some application/x-www-form-urlencoded bodies.
JSON errors worth memorizing
Most failed pastes are simple: single quotes, trailing commas, unquoted keys, comments, or smart quotes. Fix those before asking a formatter to “clean” the document—the parser must succeed first. After a successful pretty-print, skim numbers that might exceed JavaScript’s safe integer range if exact digits matter downstream.
Inspect before you replace a source
Keep a source copy when processing production strings. Title case will mangle some acronyms. Duplicate JSON keys are a smell even when parsing succeeds. Unicode edge cases can surprise you across browsers. Tools run locally and do not upload your text as part of the calculation path described on each page, but your device clipboard and extensions still exist—treat sensitive pastes carefully.
Choosing the right TextHive page
Use the counter for limits and reading estimates. Use case conversion for blunt normalization. Use JSON formatting to validate and reprint. Use URL encoding for component values. Use Base64 when a transport wants ASCII-wrapped UTF-8 text. If a task needs cryptography, schema validation, or linguistic tokenization, step outside this workbench.
What is the README link on the homepage?
It points here—the shared guide for encoding and formatting contracts across the five tools.
Why do word counts disagree elsewhere?
Other products may tokenize CJK, count code units, or strip Markdown differently. Compare rules, not only totals.
How do I report a mismatch?
Use the contact page with the exact input, tool, and expected output.
TextHive guide: pick the transform
Count words when you need volume metrics. Change case when normalizing labels. Format JSON when a payload must be readable. Encode URL components when reserved characters would break a query. Use Base64 when you need a byte-safe textual representation—never as encryption.
Counting rules matter
Word counters disagree about punctuation, hyphenation, and CJK segmentation. Read the word-count page’s rule note before citing a number in an editorial workflow. If you switch tools mid-project, keep the rule constant.
Safety for decode tools
URL decoding and Base64 decoding reveal data; they do not sanitize it. Never execute decoded strings. Never treat Base64 as a vault for API keys. Prefer redacted samples when contacting support.
Example-driven habit
For each transform, keep a tiny fixture: a JSON object with a trailing-comma mistake, a string with spaces for URL encoding, a short Unicode phrase for Base64 round-trip. Fixtures make regressions obvious and teach newcomers faster than abstract warnings.
Local processing
Transforms run in the browser. Hosting logs and browser storage are described in the privacy policy. Do not paste secrets you cannot afford to display.
Counts and encodings with explicit rules
TextHive counts words as whitespace tokens, code points via string iteration, and lines on CR/LF. It does not estimate reading duration—that belongs on planning tools. Encoding pages document UTF-8 assumptions. See text transform notes.