b2KIT

WebCrypto API Playground

Interactive playground for experimenting with the Web Crypto API - key generation, encryption, signing, and hashing.

Tested tool guide Tested browser tools Checked August 16, 2026

What WebCrypto API Playground does, with a checked example

A browser sandbox for the Web Crypto API: hash text with SHA-2, generate AES, RSA, and ECDSA keys, and encrypt, decrypt, sign, and verify, with live inputs and copyable outputs such as hex digests, base64 ciphertext, and JWK exports. Every operation runs inside the page, so key material never leaves your browser. The common surprise is that AES-GCM encryption of the same message produces different ciphertext on each run, because the browser generates a fresh random IV, and you must keep that IV with the ciphertext or decryption fails.

Worked example

A concrete input and expected output from the current implementation.

Input

hello, hashed with SHA-256 (the digest operation, which needs no key)

Expected output

2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

SHA-256 always returns a fixed-length 64-character hex digest, and the digest of the ASCII bytes "hello" is this well-known value. A matching result confirms both the playground and your own code agree with the published standard.

How the result is produced

1

Secure context requirement

The API behind the playground, crypto.subtle, is exposed only in secure contexts, meaning the page must be served over HTTPS or from localhost. Every operation returns a Promise, so results appear after an asynchronous round trip rather than instantly. On a plain HTTP origin the API does not exist at all, and the controls fail outright.

2

Keys, usages, and extractability

generateKey creates CryptoKey objects that live only in the page's JavaScript environment for the current session. Each key carries an algorithm, a list of approved usages such as encrypt, decrypt, sign, and verify, and an extractable flag. Extractable keys can be exported as JSON Web Keys and imported elsewhere; non-extractable keys remain usable but can never be exported, and they vanish when the page closes.

Good uses

  • Verifying that a digest computed in another language is correct: hash the same string here and compare the hex output against hashlib, openssl, or a published test vector.
  • Checking an encrypt-then-decrypt round trip with AES-GCM before wiring crypto into an app: encrypt a sample message, keep the IV, and confirm the ciphertext decrypts back to the original text.
  • Inspecting the exact JWK shape a browser produces for a fresh RSA or ECDSA public key, then exporting that key into a server-side configuration that expects the same format.

Limits and checks

  • Hex and base64 are display conventions, not API output: digest(), encrypt(), and sign() all return raw ArrayBuffers, and the playground formats them for readability. When comparing against another tool, compare the decoded bytes, not the character formatting.
  • Non-deterministic results are not bugs: AES-GCM and RSA-OAEP draw fresh random values on every call, so encrypting the same message twice yields different ciphertext. Only hashing and verification produce repeatable, comparable output.
  • Keys are ephemeral: a generated key exists only for the current page session and is gone after reload, and a non-extractable key can never be exported anywhere. Also, algorithm names that look alike serve different purposes - RSA-OAEP encrypts, RSA-PSS signs, and AES-GCM encrypts and decrypts but never signs.

Common questions

Does hashing here give the same result as other implementations?

Yes for digests: SHA-2 is a published standard and digest() implements it, so the hex output for a given input matches any conforming tool, which makes the playground useful for verifying test vectors. Key generation, encryption, and signing are different: they intentionally use fresh random values, so their output differs on every run and cannot be compared for equality.

Can I take a key generated here and use it in my own application?

Only if the key was created as extractable. You can then export it as a JWK and import it elsewhere via importKey, provided the algorithm and the usage list match what you generate. Non-extractable keys cannot be exported by design, and the playground does not persist keys, so once the page closes they are gone.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools