Free Online Developer Tools
Daily dev utilities you can trust with real tokens and payloads.
Developers paste real things into these tools — JWTs, API responses, internal URLs, password hashes. That makes server-side dev utilities a genuine security risk. SwiftTooly's encoder, formatter and hashing tools all run inside your browser, so you can decode that production Base64 string or hash that real password without worrying that it's now sitting in someone's request log.
4 Developer Tools
Why use SwiftTooly's Developer Tools
Token-safe
Decode JWTs and Base64 payloads without sending them through a third party's logs.
Standard algorithms
Hashes come from SubtleCrypto: SHA-1, SHA-256, SHA-384 and SHA-512, native to the browser.
Deterministic output
No AI cleanup, no opinionated formatting beyond what you ask for.
Copy-friendly
One-click copy, monospace output, clear error messages on malformed input.
Developer Tools in your browser vs uploaded to a server
SwiftTooly (browser)
Encoding, decoding and hashing run via TextEncoder, atob/btoa and SubtleCrypto inside the tab — fully offline-capable.
Typical upload-to-server tools
Online dev utilities frequently log payloads for debugging or analytics, which is the last place a production secret should end up.
Why does it matter where a developer tool runs?
The data developers paste into online utilities is unusually sensitive, and the habit of reaching for the first search result is unusually risky. A JSON payload from a staging environment routinely contains API keys, bearer tokens, internal hostnames and real customer records. A Base64 string is frequently a credential or a serialised session. A hash input may be a password being checked against a leak. A URL being decoded may carry a signed token in a query parameter. Pasting any of that into a server-side tool means transmitting it to a third party, where it may be logged, cached or retained under terms nobody read. There are documented cases of secrets leaking exactly this way. Every tool in this group runs entirely in your browser, which removes the transmission rather than promising to handle it responsibly — a materially different guarantee, and one you can verify in the Network tab.
The encoding distinctions that cause the most bugs
Three confusions account for a large share of encoding-related defects. First, Base64 is not encryption. It is trivially reversible with no key, so a token in Base64 is readable by anyone who has it — which is why HTTP Basic authentication is only acceptable over TLS and why a JWT payload should never contain secrets. Second, encodeURI and encodeURIComponent are not interchangeable. encodeURI is for a whole URL and deliberately leaves delimiters such as & and = intact; encodeURIComponent is for a single value and encodes them. Using the former on a parameter value is the classic bug, because an embedded ampersand survives and splits the parameter. Third, MD5 and SHA-1 are broken. MD5 collisions have been producible in seconds since 2004 and SHA-1 was definitively broken in 2017. Both remain fine for detecting accidental corruption and are unacceptable against a deliberate attacker. SHA-256 is the sensible default, and none of the three should ever be used to store passwords — that requires a deliberately slow function such as Argon2id or bcrypt.
Unicode, the failure that only shows up in production
A recurring pattern in these tools is that naive implementations work perfectly in testing and break the first time a real user submits anything outside basic Latin text. The browser's built-in btoa() throws an error on any character above the Latin-1 range, so Base64-encoding a name with an accent, a Chinese character or an emoji fails outright unless the string is converted to UTF-8 bytes first. Naive string reversal splits UTF-16 surrogate pairs, corrupting emoji into replacement glyphs. Percent-encoding a non-ASCII character produces multiple escape sequences because UTF-8 encodes it as multiple bytes, and code that assumes one character maps to one escape gets the length arithmetic wrong. The tools here handle all three correctly, which is worth knowing not because it is impressive but because it means testing an edge case here tells you what the correct output should be when you are debugging why your own implementation disagrees. A practical habit worth adopting: when a bug involves encoding, reproduce it with a deliberately awkward input rather than a realistic one. An emoji, an accented character, a string containing an ampersand and a plus sign, and an integer larger than 2^53 will between them expose most encoding defects in a few seconds — and all four can be tested here without sending anything anywhere.
Frequently asked questions
Is it safe to decode a real production token here?
- Yes. The Base64 decoder runs entirely in your browser using atob — nothing is uploaded. That said, treat any decoded secret as already compromised if it was ever shared elsewhere.
Which hashing algorithms are supported?
- The Hash Generator supports SHA-1, SHA-256, SHA-384 and SHA-512 via SubtleCrypto, plus MD5 via a small JavaScript implementation for legacy use.
Does the JSON formatter validate as it pretty-prints?
- Yes. Invalid JSON raises a clear error with the position of the problem rather than silently producing broken output.
What's the difference between encodeURIComponent and encodeURI?
- encodeURI preserves reserved characters used by a full URL (like : / ? &), while encodeURIComponent escapes them. The URL Encoder lets you pick the right one for your context.