Security toolbox

Be honest: how many times have you pasted a production JWT into a website?

We have all done it — along with installing a separate program to read a certificate, looking up keytool syntax again, and writing the keystore password down somewhere. None of it is carelessness. It is what happens when the tools live somewhere else.

Testnizer puts them where the request already is. The signing, the decoding and the key generation all happen on your machine, in the app's own process.

Download — free, no account How the offline model is enforced

Keystore Studio

A GUI for keytool and openssl that you do not have to memorise.

Open, create, edit, convert and export JKS and PKCS#12 keystores, and read X.509 certificates without a command line. Generate key pairs and secret keys, import PEM/DER/PFX material, match a key against its certificate, change store and entry passwords, and convert between formats in place.

JKS ⇄ PKCS#12 conversion, with what cannot survive the trip named before you commit
Certificate details — subject, issuer, SANs, key usage, validity, fingerprints
Key pair and secret key generation with the extensions spelled out, not guessed
A saved keystore can then supply the key for mTLS, WS-Security, JWT/JOSE and SAML

JWT / JOSE

A JWT debugger that never sees your token.

Decode, sign, verify, encrypt and decrypt. HS256/384/512, RS, PS and ES families, plus JWE for encrypted tokens. Verify against a pasted key, a keystore entry, or a JWKS endpoint. The header and claims are editable, and the signature is recomputed as you type.

Sign and verify — not just decode
JWE encrypt/decrypt with the key-management and content-encryption pair you choose
Verify against a live JWKS, with the algorithm allowlist pinned to the token you are holding
Available inside scripts too: pm.jose.sign / verify, identical on Send and in the Runner

JWK / JWKS

PEM in, JWK out — and a JWKS endpoint when you need one.

Convert PEM to JWK and back, generate keys directly as JWK, compute RFC 7638 thumbprints, and assemble a key set. The built-in mock server can serve that set as a JWKS endpoint, so an identity flow can be tested end to end on one machine.

PEM ⇄ JWK for RSA and EC keys
RFC 7638 thumbprints
Build a JWKS and serve it from the local mock server
Public-only export, so a private key is never handed over by accident

SAML 2.0

Build, sign and — the part that usually gets skipped — validate.

Produce an AuthnRequest or a signed assertion, sign it with XML-DSig from a PEM or a keystore entry, and validate what comes back. The validator proves which element the signature actually covers, so a document that looks signed but is not gets rejected with the reason.

Signature wrapping rejected — the validator reports which element was covered
HMAC algorithm confusion, SHA-1 and XXE refused with a stated cause
Bearer condition windows checked, including clock skew
Redirect and POST bindings, with the encoding each one requires

WS-Security

SOAP signing and encryption, attached to the request that sends it.

Sign and encrypt SOAP envelopes with X.509 tokens, choose which elements are covered, and verify a signed response. The result can be pushed straight into the SOAP request you are working on rather than copied through a text editor.

Timestamp, UsernameToken and BinarySecurityToken
Element-level signing and encryption
Verify a signed envelope and see what the signature covers
Keys come from a PEM file or a keystore entry

TLS Inspector

What a live endpoint actually presents — chain, protocol, ciphers.

Point it at a host and read the certificate chain it serves: subject and issuer, SANs, validity, signature algorithms, the negotiated protocol version and cipher, and ALPN. Useful when a handshake fails and the error message is not telling you why.

Full chain with the leaf, intermediates and what is missing
Expiry and hostname mismatch called out plainly
SNI set independently of the host, when they need to differ
A presented certificate can be saved into a keystore as trusted

This one is the exception to "works with the cable pulled": inspecting a live endpoint means connecting to it. It still uploads nothing — it reads what the server presents.

Passwords, OTP and QR

The small things you were opening a website for.

Generate passwords and passphrases with real entropy readings, keep TOTP/HOTP secrets in a local vault and read the current code, and produce or scan QR codes — including the otpauth:// kind, so enrolling a test account does not involve a phone.

Password and passphrase generation with an honest strength estimate
TOTP / HOTP vault, stored locally
QR generation and decoding, otpauth:// included
Hashing, HMAC, encoders, JWT-adjacent conversions and more in the same panel

Why we built these

Not because they did not exist.

Every one of these tools already exists somewhere. That is the problem. Each of them lives on a website, in a separate program, or in a command whose syntax you look up every time — so using one means leaving the request you were working on, and often means pasting something into a page you do not control.

In banking, government, insurance and healthcare, that habit has a name in the audit report. Not because anyone acted in bad faith, but because a production token in a browser tab is a disclosure whether or not anything went wrong.

So the point was never to build a better JWT decoder. It was to remove the reason to go somewhere else. The tools sit next to the request that needs them, the private key stays in the app core and never reaches the window you are looking at, and nothing is uploaded to be processed.

Pull the network cable and every tool on this page still works — except the TLS inspector, which exists to talk to a remote endpoint. That is the whole claim, and it is meant to be tested.

Download for macOS, Windows, Linux Read the docs