piapia123
en

Cookie Signing and Verification

Encoding

Everything runs locally in your browser — nothing is uploaded

Input
Drop a file here to load its contents
Output

A signed cookie protects against tampering, not eavesdropping: the value is still plaintext in the browser, but only a server that knows the key can produce a matching HMAC. Output is Express `cookie-signature`’s `s:<base64url(value)>.<base64url(HMAC)>`, where the HMAC covers the raw value (UTF-8 bytes). Verification first tries the algorithm you selected; if that fails it tries the other three and, when one matches, tells you the algorithm was wrong rather than a vague "signature mismatch". Comparison is byte-wise and constant-time, never short-circuiting. All computation happens locally; your key is not uploaded.

Features

  • Four HMACs: SHA-256 / SHA-384 / SHA-512 / SHA-1
  • Emits Express `cookie-signature`’s `s:` form
  • Shows the hex signature for comparing with `openssl dgst -hmac`
  • Verification separates "bad format", "bad key/value" and "wrong algorithm"
  • On an algorithm mismatch it names the algorithm that actually signed
  • Constant-time, byte-wise comparison to avoid a timing side channel
  • An empty key is rejected rather than emitting a plausible-looking fake
  • Copy a single row, or all of them

How to use

  1. Choose Sign or Verify
  2. Enter the key and pick an algorithm
  3. In Sign mode type the cookie value; in Verify mode paste the whole `s:...`
  4. Results appear at once, with a breakdown and an openssl equivalent

FAQ

Does signing hide the cookie contents?
No. Signing only proves the value was not changed — it stays plaintext and is still readable by the user and any intermediary. Use HTTPS for confidentiality, and never put secrets directly in a cookie. What signing prevents is forgery like turning user=alice into user=admin.
Why not compare signatures with `===`?
`===` returns at the first differing byte, so guessing the first bytes correctly takes marginally longer than guessing wrong. An attacker can average out that difference over many requests and recover the signature byte by byte. So this tool accumulates XOR over every byte and never short-circuits.
How should the key be kept?
The key is the entire security of the scheme. Keep it server-side only, long and random. Never ship it to the front end or send it alongside the cookie. This tool does not store what you type, but it is still a web page — handle production keys with a command on your own machine.

Related tools

HMAC

Encoding

Sign a message with a secret key using HMAC and get a result matching Node, Java and Python. The key never leaves your browser — nothing is uploaded.

Cookie Formatter

Web

Parse a Cookie request header or Set-Cookie response header into a table, pull out attributes and expiry, and flag missing HttpOnly, Secure or SameSite.

Cookie to JS

Web

Turn a cookie string into document.cookie statements for your console, or into an object literal. HttpOnly and Domain are dropped.

Base64

Encoding

Convert text to Base64 and back, with correct UTF-8 handling for accents, CJK and emoji. Runs entirely in your browser — nothing is uploaded.

URL Encode

Encoding

Escape text into %XX form and back again, treating a whole URL and a single parameter value as different jobs. Runs entirely in your browser.

HTML Entities

Encoding

Turn < > & and quotes into HTML entities and decode them back in a single pass, so &amp;lt; becomes &lt;, not an angle bracket. Runs in your browser.

← Back to all tools