Is It Safe to Paste Tokens Into Online Regex and JWT Debuggers?

Online developer tools — regex testers, JWT debuggers, base64 encoders, JSON formatters, curl command builders — are convenient and free. They also receive whatever is pasted into them. For most inputs that is fine: a regex pattern, a JSON payload, a curl command. For token-shaped inputs — a real JWT, a connection string, an API key — the website operator now has the token. Most operators do not want the token and do not store it, but the request has been received, logged, and possibly processed. The token has crossed a trust boundary it should not have crossed.

This guide is about the clipboard hygiene of online developer tools: which inputs are safe to paste, which are not, and what to use instead. It is written for developers who reach for regex101, jwt.io, and similar tools in their daily workflow. For neighbouring topics, see diffing two copied code snippets, Docker IDs, Kube contexts, and pin hygiene, and clipboard habits that keep secrets off the stack.

What online tools actually receive

When a developer pastes text into a web-based developer tool, the text:

• Reaches the website's JavaScript. The site's client-side code can read the input field's value. Most tools use this to perform the operation locally (regex testing, JWT decoding). Some tools send the input to a server for processing.
• May be sent to the website's server. Some tools perform the operation server-side. The input is in the server's request logs, possibly in the database, possibly in a third-party analytics service.
• May be sent to third-party services. Analytics, error tracking, and ad scripts running on the page can read form inputs in some configurations. This is not supposed to happen, but it has happened.
• Is stored in the browser's local storage or IndexedDB. Some tools persist input across sessions for convenience. The persistence survives a page reload and may survive a browser restart.
• Is sent over HTTPS. HTTPS protects the transport, but it does not protect against the website operator or any third-party script running on the page.

The HTTPS protection is necessary but not sufficient. It prevents a network eavesdropper from seeing the input, but it does not prevent the website operator from logging it. For non-secret inputs, this is fine. For secret inputs, it is not.

Which inputs are safe to paste

Safe to paste into any online tool:

• Regex patterns. /^[a-z]+@[a-z]+\.[a-z]{2,}$/ is a pattern, not data.
• Anonymous JSON. {"name": "test", "value": 42} is test data.
• Anonymous code snippets. A function definition without context.
• Anonymous curl commands. curl https://api.example.com/endpoint without authentication headers.
• Public URLs and identifiers. Anything already on the public internet.

For these, the website operator receiving the input is not a problem. The input has no value to an attacker.

Which inputs are not safe to paste

Not safe to paste into any online tool:

• Real JWTs. A JWT contains claims that may include user identifiers, email addresses, and roles. Even if the signature is not forgeable, the claims are sensitive. A JWT pasted into jwt.io is on jwt.io's server logs.
• API keys and bearer tokens. A real Authorization: Bearer ... header is a credential. Pasting it anywhere online is a credential exposure.
• Connection strings with passwords. mongodb://user:pass@host pasted anywhere is a password exposure.
• SSH private keys. The private key material is the credential.
• Production database queries with real data. A query that includes real user records exposes PII.
• Internal hostnames and IPs. internal-api.corp.example.com and 10.0.0.42 reveal network topology that an attacker can use.
• Stack traces from production. Stack traces often contain tokens and connection strings; see stack traces, tokens, and the clipboard for the redaction habit.

For these, use a local tool instead.

Local alternatives

Regex testing

• VS Code — the extension "Regex Previewer" highlights regex matches in the editor as you type. No data leaves the editor.
• JetBrains IDEs — the built-in regex support in the Find dialog shows match highlights and group captures.
• grep and rg — the terminal tools, with --color=always for highlighting.
• Python re module — for testing complex regexes with full control over flags and groups.

JWT decoding

• jq with base64 decoding — echo "eyJ..." | jq -R 'split(".") | .[1] | @base64d | fromjson' decodes a JWT payload locally. No data leaves the terminal.
• jwt-cli — a small CLI tool that decodes JWTs locally. Available on npm, pip, and brew.
• Python — python -c "import jwt; print(jwt.decode('eyJ...', options={'verify_signature': False}))" if the pyjwt package is installed.

JSON formatting

• jq — the standard CLI tool. echo '{"a":1,"b":2}' | jq . pretty-prints.
• VS Code — open a .json file and use Shift+Alt+F to format. Or paste into a new file and save with .json extension.
• Python — python -m json.tool reads from stdin and pretty-prints.

Base64 encoding/decoding

• base64 command — echo "hello" | base64 and echo "aGVsbG8K" | base64 -d on Linux/macOS/WSL.
• PowerShell — [Convert]::ToBase64String([Text]::Encoding::UTF8.GetBytes("hello")) and [Text]::Encoding]::UTF8.GetString([Convert]::FromBase64String("aGVsbG8K")).

Curl command building

• Postman / Insomnia / Bruno — desktop API testing tools that run locally. The request data stays on the machine.
• curl directly in the terminal — for simple cases, no tool is needed.
• httpie — a more user-friendly alternative to curl.

A workflow for "is this safe to paste"

Before pasting anything into an online tool, ask:

1. Does the input contain a credential? (Token, password, key, connection string.)
2. Does the input contain PII? (Email, phone, government ID, real user data.)
3. Does the input reveal internal infrastructure? (Hostnames, IPs, internal paths.)
4. Does the input contain proprietary code or data? (Source from a private repo, internal algorithms, business logic.)

If the answer to any of these is yes, do not paste. Use a local tool, or redact the sensitive parts first.

For developers who do this often, the habit is mechanical: before pasting, scan for token patterns (see stack traces, tokens, and the clipboard for the patterns). If any match, use a local tool.

What about "trusted" online tools

Some online tools have explicit privacy policies that promise not to store input. These policies are worth reading but are not a guarantee:

• The policy is a contract, not a technical control. A bug in the tool, a misconfigured analytics script, or a compromised server can expose input regardless of the policy.
• The policy applies to the operator, not to third parties. If the page loads analytics scripts, ad scripts, or font CDNs, those third parties see what they see.
• The policy can change. A tool that does not store input today may store it tomorrow after a feature change or an acquisition.

For non-secret inputs, "trusted" online tools are fine. For secret inputs, the trust model is not strong enough. Use a local tool.

A practical setup

For developers who want to remove the temptation of online tools entirely:

1. Install jq and add it to PATH. Covers JSON formatting and JWT decoding.
2. Install httpie or Bruno (or Postman if already invested). Covers API testing.
3. Install the Regex Previewer extension in VS Code. Covers regex testing.
4. Bookmark a local JWT decoder. Either jwt-cli or a one-line Python script in ~/.local/bin/jwt-decode.
5. Disable online tool bookmarks. Or move them to a folder named "DO NOT USE FOR SENSITIVE INPUT" as a reminder.

With this setup, the local tools are one shortcut away, and the online tools require an explicit decision to use. The friction favours the secure choice.

A note on browser extensions and clipboard access

Browser extensions can read the clipboard in some configurations. Chrome and Edge restrict clipboard access to extensions with the clipboardRead permission, which the user must grant explicitly. Firefox has similar restrictions. The risk is not that random extensions silently read the clipboard; the risk is that an extension the user installed for a legitimate purpose (a productivity tool, a password manager, a note-taking extension) has clipboard access and either logs the clipboard for its own purposes or is compromised and exfiltrates the clipboard.

The defensive habits:

• Audit installed extensions. Remove any that are no longer used or that have been acquired by unfamiliar companies.
• Prefer extensions from reputable vendors. A password manager from a known vendor is lower risk than an unknown productivity tool.
• Restrict clipboard permission. In Chrome's extension settings, you can review which extensions have clipboardRead and disable it for extensions that do not need it.
• Use a separate browser profile for sensitive work. A work profile with no extensions installed, or with only vetted extensions, reduces the attack surface for clipboard access.

This is not a call to uninstall all extensions. It is a call to be aware that the clipboard is reachable from the browser, and that the extension permission model is the control. Reviewing the model once a year is sufficient for most developers.

What about paste-and-go workflows

Some workflows require pasting into online tools because there is no local equivalent. Examples:

• Online CSV-to-JSON converters for one-off data transformation.
• Online SQL formatters that pretty-print queries.
• Online cron expression builders that explain when a schedule fires.
• Online colour palette generators for design work.

For these, the question is the same: does the input contain a credential, PII, internal infrastructure, or proprietary data? If yes, do not paste. If no, paste is fine. A CSV of test data is safe; a CSV of customer records is not. A SQL query against a test database is safe; a SQL query with embedded customer IDs from production is not.

The discipline is the same as for regex testers and JWT debuggers: scan the input for sensitive patterns before pasting. If any pattern matches, find a local alternative or redact first. For most one-off transformations, a local tool exists; the online tool is faster but not safer. The trade-off is the developer's to make, with full awareness of what is being sent where.

Related reading

• Docker IDs, Kube Contexts, and Pin Hygiene
• Copying From man Pages and --help Without Soft Wraps
• Best Clipboard Habits for Developers in 2026
• Clipboard Tools on Multi-Monitor Windows Setups

Sources

• OWASP — Sensitive data exposure cheat sheet — reference for what counts as sensitive data and how to handle it
• jwt.io — privacy notice — the privacy policy of a popular online JWT decoder; worth reading to understand what data the site receives and what it does with the data
• jq — GitHub README — official documentation for jq, the standard CLI JSON processor that can decode JWTs locally
• regex101 — about page — the privacy policy of a popular online regex tester; the site does state that it does not store regexes, but the policy is a contract, not a technical guarantee
• Bruno — GitHub README — open-source, locally-running API client; the privacy-respecting alternative to Postman's cloud features

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support