You have done this. Every developer has. You need to decode a JWT, so you google “JWT decoder” and paste your token into the first result. You need to pretty-print some JSON, so you paste your API response — complete with access tokens and user data — into an online formatter. You need to diff two config files, so you paste both into a web-based diff checker.
You know you should not be doing this. You do it anyway, because the alternative is firing up a terminal tool or writing a quick script, and you just want the answer now.
The text that developers paste into random websites#
Think about what actually gets pasted into online text tools on a daily basis:
- JWT tokens containing user IDs, permissions, and session data
- JSON configs with API keys, database credentials, and service endpoints
- YAML files with deployment secrets and infrastructure configuration
- Base64-encoded strings that decode to authentication credentials
- Source code pasted into diff checkers containing proprietary business logic
- CSV exports with customer data, email addresses, and internal metrics
- Environment variables with production secrets
- URL query strings with session tokens and API parameters
This is not hypothetical. This is what developers do every day, across every company, at every level of seniority. The operations are simple — format, decode, diff, convert — but the data is sensitive.
Why the convenience trap persists#
The reason this pattern persists is not that developers are careless. It is that the friction of the secure alternative is just high enough to lose to the convenience of the insecure one. Opening a terminal, remembering the right command, piping output through jq or base64 — it takes thirty seconds instead of five. And thirty seconds feels like too long when you just want to see the decoded payload.
Online text tools exploit this gap. They offer zero-friction interfaces for operations that developers need constantly. The implicit trade is: give us your data, and we will save you thirty seconds. Most developers take that trade without thinking about where their data goes.
The sites themselves are often ad-supported, which means they are incentivized to maximize pageviews, not to protect user data. Their privacy policies — if they have them — are boilerplate. Their server-side processing means your text hits their infrastructure, gets logged, and exists on hardware you do not control. Some of these sites are run by solo developers with good intentions. Some are not. You have no way to tell the difference from the UI.
What I built to solve this for myself#
I built MyText because I was tired of the cognitive dissonance. I knew I should not be pasting sensitive text into random websites. I did it anyway because the tools were convenient and the alternatives were not. The fix was obvious: build the same tools, running entirely in the browser, with no server-side processing.
Every one of the 161 tools on MyText runs client-side. No data is transmitted to any server. The only things stored on your machine are your theme preference, language selection, and favorited tools. This is the same client-side architecture I use across PDF Pony, ImageNurse, and GIS Tools. The principle is consistent: if the browser can do the computation, the server should not touch the data.
The operations that should never leave your machine#
Some text operations are inherently sensitive, and developers should treat them that way:
Decoding and encoding. JWT decoding, Base64 decoding, URL decoding — these operations often reveal credentials, session data, and personally identifiable information. Pasting encoded strings into a server-side decoder defeats the purpose of encoding.
Hashing. If you are using a SHA hash generator or MD5 generator to hash sensitive values, sending those values to a server for hashing is a contradiction.
Format validation. JSON linting, YAML validation, XML validation — these operations are frequently performed on configuration files that contain secrets. The validation itself is trivial; the data being validated is not.
Diffing. A whitespace diff on a production config file should not route through a third-party server. Neither should comparing two versions of a contract or internal document.
Extraction. Pulling email addresses, URLs, or dates from internal documents means pasting those entire documents into the tool. The extracted data is sensitive, and so is the source text.
A toolbox that stays on your machine#
I built MyText as the toolbox I wanted — 161 text operations that run locally, load offline, and never transmit data. I internationalized it into eight languages because the need for private text tools is universal, not just English-speaking.
The next time you are about to paste a JWT token into a random website, consider where that token is going. Then consider whether the operation you need really requires a server.
MyText processes everything locally and works offline.
