The handful you actually use every day
Backend work usually means four things: checking whether an API response is valid (JSON formatting), turning a timestamp into readable time, verifying a hash, or encoding a file as Base64 for a request. Front-end work is regex, colours, CSS units and figuring out when a cron expression fires. Each job takes under a minute but may repeat a dozen times a day, which is exactly why it belongs on one page.
Data formats: let types follow the data
Given an API response, the fastest route is generating type definitions in the target language: TypeScript interfaces, Go structs with json tags, Java records, Python dataclasses, Rust structs. That removes transcription mistakes in field names and optionality. Converting between JSON and YAML, watch two things: YAML 1.1 turns yes/no into booleans (verify the target’s expectations) and comments plus anchors are lost. For CSV and JSON, mind delimiters and quoting — fields containing commas must be quoted.
Encoding and hashing: know the purpose before you start
This is the most confused area. Base64 is only encoding — anyone can reverse it, so it protects nothing. Hashing (MD5/SHA-256) is a one-way digest for integrity checks, not encryption. A JWT header and payload are Base64 encoded rather than encrypted, so decoding one to look inside is routine, but never treat that as verification: signature checks belong on the server. MD5 and SHA-1 are known to be collision-prone; start new systems at SHA-256 or better.
Regex and text: prove it on a small sample first
Write the pattern against a few sample lines, confirm matches and capture groups, then run it on the full dataset. Live highlighting and group inspection beat printing to the console. Watch for syntax differences between languages (named groups differ between JavaScript and Python) and for the scope of the g, i, m and s flags. Most text jobs land on this line: bulk case conversion, Chinese simplified/traditional conversion, whitespace clean-up, and diffing two versions.
Front-end and styling: small tools save debugging time
Converting colours between HEX, RGB and HSL, tuning a gradient visually and copying the CSS, turning design px into rem or vw, checking whether contrast clears WCAG 4.5:1 — none of it is hard, but every hand calculation invites mistakes. When generating CSS, check three things: units are consistent (mixing px and rem breaks proportional scaling), shadow layers are few (they cost performance on low-end devices), and dark-theme contrast is sufficient.
Why local processing matters especially for developers
What you paste may contain production connection strings, customer phone numbers, private key fragments or internal hostnames. Sending that text to an unfamiliar service hands over company assets — and even a promise of "no logging" cannot be audited. Every tool here executes in the browser, sends no requests and keeps no copy; you can verify by going offline. It is also why we deliberately do not offer "sign in to save history".
FAQ
Is it safe to paste code containing secrets?
In these tools, yes: parsing happens in browser memory with no network requests. The real leak paths are public issues, chat logs and screenshots — mind those instead.
After decoding a JWT, is the signature still verified?
This tool only decodes: you can read the header and payload, but that proves nothing about tampering. Signature and expiry validation must happen server-side with the key.
Is there batch processing?
Text tools handle line-by-line batches (encoding or converting row by row), but keep volumes sensible — tens of thousands of lines belong in a script.