DevKit — Developer Tools That Stay in Your Browser
JSON formatting, Base64, hashing, JWT decoding, URL encoding, timestamps, and regex — all processed locally. Your API keys, tokens, and code are never transmitted anywhere.
DevKit Browser Developer Tools
JSON Formatter & Validator
Paste JSON to format, minify, or validate it. Press Ctrl+Enter to format. Processed entirely in your browser — no JSON is transmitted anywhere.
Base64 Encoder / Decoder
Encode text or files to Base64, or decode a Base64 string back to text. Supports full Unicode and binary files. Nothing is uploaded — all encoding is done in your browser.
Hash Generator
Generate SHA-1, SHA-256, SHA-384, and SHA-512 hashes from text or files using the browser's Web Crypto API. No data is sent to any server — hashing runs entirely on your device.
URL Encoder / Decoder
Encode or decode URLs and query string values using encodeURIComponent and encodeURI. Useful for building API requests, sanitising query params, or debugging redirect chains.
JWT Decoder
Decode and inspect any JSON Web Token — header, payload, and signature — without verifying the signature server-side. Expiry is checked against your local clock. Your token never leaves your browser.
Header
Payload
Signature (encoded)
⚠ Signature is shown but not verified — signature verification requires the secret key and must be done server-side.
Unix Timestamp Converter
Convert Unix timestamps to human-readable dates, or pick a date and get its Unix timestamp. Supports both seconds and milliseconds.
Unix → Human Date
Date → Unix Timestamp
Regex Tester
Write a regular expression and test it against a string with live match highlighting. Supports all JavaScript RegExp flags. Your patterns and test data stay local.
How to Use DevKit
Choose from the seven tabs at the top: JSON, Base64, Hash, URL, JWT, Timestamp, or Regex. Each tab switches the input panel to a different tool. All seven tools are loaded on the same page, so switching is instant with no page reload.
Enter your data into the input field — a JSON response, a Base64 string, raw text, a JWT token, a Unix timestamp, or a regex pattern. For the Hash and Base64 tools you can also click 📎 Hash File or 📎 Encode File to process a local file directly without uploading it anywhere.
Hit the primary button for the operation you want — ▶ Format, ▶ Encode, ▶ Generate Hashes, and so on. The JSON Formatter also responds to Ctrl+Enter so you never have to lift your hands from the keyboard. The Regex Tester updates live as you type — no button needed.
Below each panel a status bar confirms the result — the number of JSON keys found, whether a JWT is expired, the number of regex matches, or an error message with the exact character position of a syntax problem. This feedback is designed to save you the round-trip of pasting into a separate validator.
Each tool provides a Copy button next to the output. Formatted JSON, encoded strings, and hash values are copied to your clipboard in one click, ready to paste into your editor, terminal, or API client. Hash rows each have their own Copy button so you can grab just the algorithm you need.
What Each DevKit Tool Does
DevKit bundles seven utilities that developers reach for several times a day, each backed by a browser-native API with zero server involvement.
- JSON Formatter & Validator — Formats minified JSON into readable indented output, minifies it back for transmission, and validates syntax using the browser's own
JSON.parse()engine, which reports the exact error position. - Base64 Encoder / Decoder — Encodes plain text or binary files to Base64 and decodes Base64 strings back to text. Handles full Unicode and common binary formats, with file support for generating data URIs and inspecting PEM certificates.
- Hash Generator — Computes SHA-1, SHA-256, SHA-384, and SHA-512 digests for typed text or local files using the browser's
SubtleCryptoAPI. Use SHA-256 to verify a downloaded file against a published checksum. - URL Encoder / Decoder — Applies
encodeURIComponent()for individual query string values andencodeURI()for complete URLs, covering the two most common percent-encoding scenarios in API work. - JWT Decoder — Splits a JSON Web Token into its three parts (header, payload, signature), formats the claims as readable JSON, and flags whether the token's
expclaim has already passed — useful when debugging authentication issues in staging. - Unix Timestamp Converter — Converts Unix timestamps (seconds or milliseconds) to human-readable UTC and local time, and converts dates back to timestamps. Handles the
iatandexpvalues from JWT payloads directly. - Regex Tester — Tests a JavaScript regular expression against a string with live match highlighting and a match list showing each match's value and position. Supports all ECMAScript flags (
g,i,m,s) and named capture groups.
Common Use Cases
- Debugging an API response — Paste a minified JSON body from Postman or your browser's Network tab into the JSON Formatter. The indented output makes it easy to navigate nested objects, find unexpected null values, and spot missing fields before writing a bug report.
- Verifying a downloaded file's integrity — Drop the file into the Hash Generator, select SHA-256, and compare the output against the checksum published on the download page. A mismatch means the file was corrupted in transit or tampered with.
- Inspecting a JWT during API development — Paste the bearer token from an Authorization header into the JWT Decoder to read the payload claims and check whether the token has expired. No secret key is needed or entered — safe for use during local development and code review.
- Building and testing regex patterns — Write a pattern for email validation, log parsing, or data extraction in the Regex Tester and paste real sample data to see which lines match before embedding the expression in production code. The live highlight makes it immediately obvious when a pattern is over-matching or under-matching.
Related reading on the privotools blog: How to Read a JWT Without a Library and Verifying File Integrity with SHA-256.
How DevKit Works
DevKit is a collection of seven browser-based developer utilities, each one backed by a standard Web API rather than a remote server. When you click a button, your browser executes JavaScript that was already loaded on the page — no data is transmitted anywhere. You can verify this yourself by opening your browser's Developer Tools (F12), switching to the Network tab, and using any DevKit tool. You will see zero outgoing requests.
The privotools infrastructure serves only the HTML, CSS, and JavaScript files that run the tools. After those files load, the server is out of the picture entirely. Your JSON responses, API keys, tokens, and file hashes are processed inside your browser's process and discarded when you close the tab.
JSON Formatter & Validator
Uses JSON.parse() and JSON.stringify() — the browser's native JSON engine. Malformed JSON surfaces the exact error message and position from the engine itself, which is more accurate than any custom parser. Press Ctrl+Enter to format without reaching for the mouse.
Base64 Encoder / Decoder
Uses TextEncoder, atob(), and btoa() — built-in browser APIs with no third-party dependency. Full Unicode text is handled correctly. The file encoder uses the FileReader API to read the file locally and produce a Base64 data URI, never uploading the file.
Hash Generator
Uses window.crypto.subtle.digest() — the SubtleCrypto API that is also responsible for HTTPS key material in your browser. This is the same cryptographic engine your browser trusts for TLS sessions. No third-party hashing library is bundled or loaded.
URL Encoder / Decoder
Uses encodeURIComponent(), encodeURI(), decodeURIComponent(), and decodeURI() — the four URL-handling functions built into every JavaScript runtime. The difference between component and full-URL encoding is explained inline so you choose the right one for the job.
JWT Decoder
Uses Base64 URL decoding (a slight variant of standard Base64) followed by JSON.parse() on each dot-separated JWT part. Expiry is checked against your device's local clock using Date.now(). No jsonwebtoken npm package, no network request, no secret key required.
Unix Timestamp Converter
Uses JavaScript's built-in Date object — new Date(ms), .toUTCString(), .toISOString(), and .toLocaleString(). Relative time (e.g., "3 hours ago") is calculated from Date.now(). Everything is your browser's native date handling.
Regex Tester
Uses JavaScript's native RegExp constructor and .exec() — the same regex engine that powers your Node.js backend and V8-based tooling. Live match highlighting is rendered by a transparent overlay positioned precisely over the textarea, with no DOM mutation of the input text itself.
Why Sensitive Developer Data Should Never Leave Your Browser
Most online developer tools — JSON formatters, JWT decoders, hash generators — are implemented as server-side applications. When you paste data into one of these tools, it travels over the internet to a third-party server, is processed there, and the result is returned. Even if the operator has good intentions, you have no way to verify what happens to your data after it leaves your machine.
This matters more than it might seem, because the inputs to developer tools are routinely sensitive:
- JWT tokens contain user IDs, email addresses, roles, and session claims. A valid JWT from a production environment is effectively a credential scoped to that user's session.
- Base64 strings from API integrations often encode API keys, client secrets, or HTTP Basic Authentication credentials. Decoding them on a remote server hands that server your credentials in plaintext.
- JSON payloads copied from API response logs frequently include personally identifiable information — names, addresses, phone numbers, health data — that should not leave your network perimeter.
- Files submitted to hash generators are, by definition, seen by the server computing the hash. If the file is proprietary source code, a private document, or a configuration file, that is an unacceptable data exposure.
- Regex patterns used to validate internal formats can reveal details about your data schema, validation logic, and identifier formats to a third party.
DevKit processes everything inside your browser's sandboxed JavaScript environment. There is no HTTP request to any backend — because there is no backend. The network stays idle from the moment the page finishes loading until you navigate away.
Who Uses DevKit
DevKit is designed for anyone working with APIs, tokens, data formats, and code — who wants the assurance that their inputs are never transmitted to a third-party server.
- Backend and full-stack developers debugging API integrations reach for DevKit when they need to quickly inspect a JWT from a staging environment, format a large JSON response for readability, or verify the SHA-256 hash of a downloaded dependency before running it. These are daily tasks where using a remote tool introduces unnecessary risk.
- Frontend developers use the URL encoder to construct valid query strings for fetch calls, the Base64 encoder to embed small images as data URIs in CSS without an extra HTTP request, and the Regex Tester to iterate quickly on validation patterns for form inputs.
- DevOps and platform engineers use the Hash Generator to verify file integrity checksums for infrastructure artefacts, decode JWTs issued by their identity provider to inspect custom claims, and convert Unix timestamps from server logs into readable dates when correlating incidents across systems.
- Security engineers and penetration testers use DevKit to inspect JWT structure and expiry during authentication flow analysis, decode Base64-encoded payloads found in HTTP intercepts, and test regex patterns for input validation bypasses — all without sending potentially sensitive payloads to an external tool.
- Technical writers and developer advocates producing API documentation use the JSON Formatter to produce clean, consistently indented examples, and the URL Encoder to generate properly percent-encoded example URLs for their reference material.
- Students learning web development use DevKit to see how JWT structure works in practice, understand what Base64 encoding actually does to a string, and experiment with regular expressions in a visual, immediate environment before applying patterns in real code.
Tips & Best Practices
- Use SHA-256 as your default hash algorithm. SHA-256 offers an excellent balance between security and performance and is the most widely used algorithm for file integrity verification, digital signatures, and HMAC tokens. Use SHA-512 when hashing high-value data such as cryptographic key material or when regulations require it. Avoid SHA-1 for any new security-critical application — it has known collision vulnerabilities and is deprecated by NIST.
- Use
encodeURIComponent()for query parameter values, notencodeURI(). A common mistake is applyingencodeURI()to a single query value. BecauseencodeURI()preserves characters like&,=, and+, a value containing these characters will corrupt the query string. UseencodeURIComponent()for any value going inside a URL, then construct the full URL around it. - Check JWT expiry before debugging authentication issues. The single most common reason a JWT stops working is expiry. Paste the token into the JWT Decoder first and check the expiry badge — it will immediately tell you if the token is expired and by how much. This rules out the most frequent cause in under five seconds before you start investigating signing keys or claim logic.
- Prefer passphrases to Base64-encoded random bytes for human-readable secrets. If you need an API key that a developer will type or paste manually, a Base64-encoded random string (generated elsewhere and encoded here) is compact but error-prone to transcribe. A long random string with a clear structure is often more practical for shared team secrets that need to be communicated verbally or written down temporarily.
- Use the
m(multiline) flag in the Regex Tester when your input spans multiple lines. Without themflag,^and$match only the very start and end of the entire string. Withmenabled, they match the start and end of each line — which is almost always what you want when processing multi-line log files, CSV content, or multi-paragraph text. - Hash files locally before uploading to cloud storage. Compute a SHA-256 hash of a file in DevKit before uploading it to S3, GCS, or any cloud service. After the upload, hash the downloaded copy and compare. If the hashes match, the file was not corrupted or tampered with in transit. This is a simple integrity check that requires no additional tooling beyond your browser.
Reference: SHA Hash Algorithms & Common Use Cases
Use these tables as a quick reference when choosing a hash algorithm or deciding which encoding or format to use for a given task.
| Algorithm | Output Size | Security Status | Common Use Cases |
|---|---|---|---|
| SHA-1 | 160 bits (40 hex chars) | ⚠ Deprecated for security use — collision attacks exist | Legacy checksums, Git object IDs, SVN, older certificate fingerprints |
| SHA-256 | 256 bits (64 hex chars) | ✓ Recommended — widely supported | File integrity, HMAC tokens, TLS certificates, JWT HS256/RS256, S3 ETags |
| SHA-384 | 384 bits (96 hex chars) | ✓ Strong — higher security margin | Subresource Integrity (SRI) hashes, ECDSA P-384 signatures, federal/compliance systems |
| SHA-512 | 512 bits (128 hex chars) | ✓ Very strong — highest SHA-2 security margin | Password hashing (pre-bcrypt step), key derivation inputs, long-term archive integrity |
| Encoding / Format | Tool | Typical Use Case | Notes |
|---|---|---|---|
| Base64 (standard) | Base64 tab | HTTP Basic Auth, email attachments (MIME), data URIs in HTML/CSS | Uses + and /; safe in headers, unsafe in URLs without escaping |
| Base64 URL-safe | Base64 tab (JWT sig) | JWT signatures, OAuth 2.0 PKCE code_verifier, URL-safe binary tokens | Replaces +→- and /→_; omits padding = |
| Percent encoding (component) | URL tab | Query string values, form data, path parameters with special characters | encodeURIComponent(); encodes &, =, +, / |
| Percent encoding (full URL) | URL tab | Encoding a complete URL before embedding it as a redirect parameter | encodeURI(); preserves URL structure characters like ://, /, ? |
| Unix timestamp (seconds) | Timestamp tab | JWT iat/exp claims, database created_at columns, POSIX system calls |
Standard across all Unix systems; use milliseconds only for JavaScript-specific APIs |
| ISO 8601 | Timestamp tab | JSON API date fields, logs, configuration files, HTML datetime attributes |
e.g., 2024-05-20T14:30:00.000Z; timezone-unambiguous and sortable as a string |
Frequently Asked Questions
Is it safe to paste JWT tokens into DevKit?
Yes. The JWT decoder runs entirely in your browser — the token is never sent to any server. You can verify this yourself by opening the browser's Network tab in DevTools before pasting a token: you will see zero outgoing requests triggered by the decode operation. The privotools servers only deliver the HTML, CSS, and JavaScript; they never see any token you paste.
Does the Hash Generator support MD5?
No. The browser's SubtleCrypto API explicitly excludes MD5 because it is cryptographically broken — practical collision attacks have existed since 2004. DevKit supports SHA-1 (still common for non-security checksums like Git object IDs), SHA-256, SHA-384, and SHA-512. If you specifically need MD5, a dedicated CLI tool such as md5sum on Linux/macOS or certutil on Windows is the appropriate choice.
Why are there two URL encoding options?
encodeURIComponent() encodes everything that is unsafe inside a query string value, including /, ?, &, and =. Use this when encoding a single value that will be embedded inside a URL. encodeURI() preserves all URL-structural characters (://, /, ?, #, &) and is intended for encoding a complete, pre-constructed URL — for example, before placing it as a redirect parameter.
Can the JWT Decoder verify the signature?
No, by design. Verifying a JWT signature requires the secret key (for HMAC algorithms like HS256) or the public key (for asymmetric algorithms like RS256 or ES256). Entering a secret key or private key into any browser-based tool — even a privacy-respecting one — is not best practice, as it exposes the key to the browser's JavaScript environment. Signature verification should be done in your application using a trusted library such as jsonwebtoken (Node.js), python-jose (Python), or golang-jwt/jwt (Go). DevKit decodes and displays the payload claims so you can inspect them without needing the signature secret.
What SHA algorithm should I use for file integrity checks?
SHA-256 is the right choice for the vast majority of file integrity verification tasks. It is the algorithm used by package managers (npm, pip, cargo), cloud storage ETags, and most modern checksum files. Use SHA-512 if you are working in a compliance-regulated environment that requires it, or when hashing cryptographic key material. Avoid SHA-1 for new integrity checks — collision attacks mean that a determined attacker could craft two different files with the same SHA-1 hash.
What is Base64 used for in web development?
Base64 is used in several common web development contexts: encoding binary data (images, fonts, icons) as data URIs so they can be embedded directly in HTML or CSS without a separate HTTP request; encoding credentials for HTTP Basic Authentication headers (the Authorization: Basic <base64(user:pass)> pattern); representing binary data in JSON API payloads that only support text; and encoding cryptographic keys and certificates in PEM format. The JWT standard uses a URL-safe variant of Base64 (replacing + with - and / with _) to encode the header and payload sections.
Does the Regex Tester support named capture groups?
Yes. The tester uses JavaScript's native RegExp engine, which in modern browsers supports named capture groups ((?<name>...)), lookaheads ((?=...) and (?!...)), lookbehinds ((?<=...) and (?<!...)), Unicode property escapes (\p{Letter}), and all other features of the ECMAScript 2023 regex specification. The same patterns that work in DevKit will work in your Node.js backend or browser-side JavaScript without modification.
What is a Unix timestamp and why do APIs use it?
A Unix timestamp is the number of seconds (or sometimes milliseconds) elapsed since January 1, 1970, 00:00:00 UTC — the Unix Epoch. It is a timezone-independent, locale-independent integer representation of an exact moment in time, making it easy to store in a database, compare programmatically, and transmit in a JSON payload without ambiguity. JWTs use Unix timestamps (in seconds) for the iat (issued-at) and exp (expiry) claims. Most server-side logging systems emit Unix timestamps for the same reason. The Timestamp Converter in DevKit handles both second-precision and millisecond-precision values.
Do any of these tools require an internet connection to work?
An internet connection is needed only for the initial page load, which fetches the HTML, CSS, and JavaScript files. Once the page is fully loaded, all seven tools operate entirely offline — there is no server dependency for any processing operation. If your connection drops mid-session, the tools continue to function without interruption.
Is DevKit free to use?
Yes, completely free. DevKit is part of privotools, which is supported by Google AdSense advertising. There is no subscription, no sign-up, no account required, and no usage limit on any tool.