Decode and verify django.core.signing values (signed cookies, sessions, password-reset tokens). Everything runs in your browser - nothing is uploaded.
Django signed values are payload:timestamp:signature. The payload is URL-safe base64 (zlib-compressed when prefixed with a dot). The signature is HMAC-SHA256 keyed by SHA-256(salt + "signer" + SECRET_KEY). Provide SECRET_KEY to verify authenticity; leave it blank to just inspect the payload. Session cookies use the salt shown above; signing.dumps defaults to "django.core.signing".
Decode and verify Django signed cookies, sessions and tokens (django.core.signing). Optionally check the HMAC-SHA256 signature with your SECRET_KEY. Runs entirely in your browser.
Django signs cookies, sessions, password-reset links and other values with django.core.signing. Signed values are not encrypted - they are base64-encoded and protected by an HMAC-SHA256 signature derived from the project's SECRET_KEY. This tool decodes the payload and, when you supply the SECRET_KEY, verifies the signature locally in your browser, for debugging, forensics and authorized inspection of applications you control.
Input:
eyJ1c2VyIjoxfQ:1abc2d:Xy9...signature + SECRET_KEY
Output:
{"user":1,"admin":true} (signature valid)Are Django sessions encrypted?
No. The signed_cookies backend only signs the data; it is readable by anyone. The signature stops tampering, it does not hide contents. Decode works without the SECRET_KEY.
Do I need the SECRET_KEY?
Only to verify the signature. Leave it blank to just decode the payload. With it, the tool confirms the value was issued by the app and is unmodified.
What salt should I use?
Session cookies use django.contrib.sessions.backends.signed_cookies. Generic signing.dumps uses django.core.signing. Password-reset and other features use their own salts.
Is anything uploaded?
No. The signed value and SECRET_KEY are processed entirely in your browser.