14 tools

Developer tools

Inspect, encode, decode, and transform developer data. Choose a task and open the matching tool.

Developer tools

Use JSON Formatter and Regex Tester to inspect structure and matches. Base64, URL, and HTML tools encode or decode text, while timestamp, hash, JWT, UUID, and secure-token tools handle other developer data.

Decoded data is not automatically trusted. JWT Decoder does not verify signatures, hashes and Base64 are not encryption, and random tokens still need secure storage, rotation, scope, and expiry.

Developer utilities often accept similar-looking strings while answering very different questions. Start by naming the job. JSON Formatter asks whether text parses as JSON and rewrites that parsed value. Regex Tester asks where a JavaScript pattern matches sample text. Base64 Encode and Base64 Decode change how UTF-8 text is represented. JWT Decoder exposes two JSON sections from a token without deciding whether the token is trustworthy.

Generation jobs have another shape. Hash Generator derives a deterministic SHA digest from entered text, so identical UTF-8 bytes and algorithm produce identical hexadecimal output. UUID Generator requests fresh random version 4 identifiers from the browser. Timestamp Converter moves between a date-time representation and Unix seconds or milliseconds. One tool fingerprints content, another makes unrelated IDs, and the third interprets time.

Write a one-line acceptance check before opening a workbench. Examples include: the response must parse and remain an array; this pattern must capture every invoice code; the decoded token should show the staging issuer; or the 13-digit event value should point to the incident window. That sentence determines which output deserves review.

Choose JSON Formatter when the entire input is meant to follow JSON grammar. It uses the browser parser, then serializes the value in a two-space or minified form. Parsing catches malformed commas, quotes, escapes, brackets, and unsupported JavaScript syntax. It does not check an API schema, required fields, business rules, or the safety of values inside strings.

Choose Regex Tester when the target is a local text pattern rather than a complete data format. It runs JavaScript RegExp syntax with global, case-insensitive, and multiline combinations offered by the page, then shows match positions and captured values. The reported index follows JavaScript UTF-16 string positions. A regex match can locate a candidate identifier, but it does not prove that the surrounding record is valid.

Do not use a regular expression as a substitute for a JSON parser. Escaped quotes and nested objects make that approach fragile. Conversely, JSON parsing cannot find invoice numbers inside unstructured logs unless the log has already been divided into JSON records. In a mixed workflow, isolate each record first, parse structured parts, and apply small patterns only to fields whose contract calls for patterned text.

Base64 Encode converts entered text to UTF-8 bytes and writes standard padded Base64. Base64 Decode accepts standard or common URL-safe substitutions, restores padding, and interprets recovered bytes as UTF-8. These tools are useful for controlled API examples, encoded text fields, and transport troubleshooting. Neither operation hides information from anyone who can access the value.

Confirm which alphabet the destination specifies. Standard Base64 includes `+` and `/`; Base64url uses `-` and `_` and often omits equals padding. The encoder returns standard form, while the decoder normalizes the URL-safe substitutions. A protocol can add its own wrapper, such as a data URL prefix or authorization scheme, which should not be mistaken for encoded body text.

Base64 can represent binary bytes, but this catalog's fields are text-oriented. The encoder starts from UTF-8 text, and the decoder displays UTF-8 text. Use a file-aware byte tool for images, archives, executables, or encrypted data. Replacement symbols in decoded output often signal non-UTF-8 or binary content rather than a formatting problem.

JWT Decoder requires three dot-separated parts, decodes the header and payload as Base64url JSON, and prints a fixed notice that the signature was not verified. This view helps identify issuer, audience, subject, token times, key identifiers, and custom claim shapes during debugging. It cannot establish identity, authorization, integrity, or current validity.

A complete authentication check belongs in a maintained JOSE or identity library. The verifier must restrict algorithms, select trusted public or shared keys, validate the signature, and enforce issuer, audience, time, and required-claim policy. An attacker can manufacture a readable payload, so visual inspection must never replace those checks.

Take numeric `exp`, `nbf`, or `iat` values to Timestamp Converter only after remembering that JWT numeric dates use Unix seconds. The date display can explain a time-related hypothesis, but it still does not cover clock tolerance, revocation, session state, or signature validity. Keep live bearer tokens out of screenshots, logs, tickets, and shared clipboards.

Hash Generator supports SHA-256, SHA-384, and SHA-512 through Web Crypto. It converts entered text to UTF-8 before producing lowercase hexadecimal. Use it when the same exact byte sequence should yield the same fingerprint. An added line break, changed encoding, or different serialization changes the digest, even if the information appears equivalent to a reader.

UUID Generator uses the browser's secure `crypto.randomUUID()` function and produces version 4 values, one per line, with a maximum request of 100. Use those values for new record identities, fixtures, or distributed creation where v4 fits the design. The generator does not reserve IDs, check a database, or create deterministic names from content.

A hash should not be used as a random record ID without a defined content-addressing design, and a UUID cannot confirm content integrity. Neither is a password-storage solution or access-control decision. Databases should enforce uniqueness for identifiers, while integrity workflows need a trusted expected digest or authenticated manifest.

Timestamp Converter treats 9- or 10-digit numeric input as Unix seconds and 11 through 13 digits as milliseconds. Other input goes through JavaScript date parsing. The output shows browser-local time, UTC, ISO, Unix seconds, and Unix milliseconds. Its length rule is useful for current-era values but cannot infer every historical, far-future, or domain-specific unit.

A date near January 1970 often indicates that milliseconds were mistaken for seconds. A wildly distant date can signal the reverse. Read the field schema, variable name, or producer documentation before accepting a conversion. Date strings should include `Z` or an offset when they represent a shared instant; zone-free strings can depend on device rules.

The converter works at JavaScript Date's millisecond precision. It does not preserve microseconds or nanoseconds, choose an arbitrary display zone, parse durations, or decide which business boundary applies. Keep unit and zone semantics beside stored values, particularly for logs, cache expiry, billing events, and authentication claims.

Layered values are easier to diagnose when every stage has a named input and output. A token investigation might begin by isolating the compact JWT, decoding its claims, converting numeric dates, and finally reproducing the verifier error in application code. A data-field investigation might decode Base64, parse the recovered JSON, then test one field against a JavaScript pattern.

Keep the original at each stage. If a transformation fails, return to the last confirmed boundary instead of editing characters until something looks readable. Record whether quotation marks, URL percent escapes, authorization schemes, or MIME headers were removed. Those wrappers belong to specific protocols and should be handled by their parsers.

Move the confirmed case into an automated test. Include exact input, encoding, flags, algorithm, time unit, and expected result as applicable. Browser inspection helps isolate the bug, while a test in the production runtime prevents the same assumption from returning after a library or environment change.

These developer workbenches process input on the device rather than sending the entered value to a PWRKIT processing server. The page, browser memory, clipboard, extensions, session recovery, screen sharing, and managed-device controls can still expose it. Use disposable samples wherever a production secret, token, identifier mapping, or personal record would otherwise be required.

Readable output is not necessarily safe output. Decoded text can contain commands, script, markup, URLs, or malicious payloads. JSON values remain untrusted until validated for their destination. A hash of a predictable identifier can be guessed from candidate values, and a UUID becomes sensitive once linked to a protected record.

Clear the workbench after a sensitive debugging session and follow the organization's clipboard and incident rules. If a bearer token or credential was exposed, revoke or rotate it according to the owning system. Do not rely on Base64, hashing, a generic filename, or an expired browser tab to protect data.

A successful workbench action proves only that the browser completed its local operation. Paste formatted JSON into the schema validator, run the regex in the target JavaScript runtime, and test encoded values against the documented endpoint. Compare hashes using the required algorithm and raw byte source. Insert generated UUIDs under a database unique constraint.

For time and identity work, repeat the check in the system that owns policy. Confirm timestamp unit, zone, and precision at the API boundary. Let the authentication library verify a JWT and report a specific failure. Avoid changing validation settings merely to align production with a browser display.

Keep an evidence note for consequential debugging: sanitized source reference, selected operation, settings, result, target runtime, and final check. This makes the browser output a traceable diagnostic aid instead of an unexplained string copied into code or configuration.

A readable string can still be the wrong interpretation. Base64-decoded bytes might be binary, a numeric field might use microseconds, and token claims might be attacker-controlled. Stop when the producer's contract is unknown. Record the candidate format and obtain a sample or schema instead of stacking decoders until words appear.

Successful parsing also has a narrow meaning. JSON syntax acceptance does not validate field types against an API contract. A regular-expression match does not establish that a whole value is allowed. A timestamp date does not identify which event the field represents. Name the remaining validation after every local tool result.

Generated output requires ownership. Store UUID assignments where the records are created, and label SHA values with their algorithm and byte source. Untracked values copied from a browser can be reused accidentally or compared under the wrong assumptions. Production code should generate and persist them inside a controlled transaction or build process.

When one task crosses several formats, draw the boundary order before processing. URL wrapping, Base64 representation, JSON parsing, claim inspection, and signature verification are separate layers. Reversing two layers or skipping one can create an output that looks reasonable but no longer corresponds to the source protocol.