b2KIT

Session Token Entropy Analyzer

Analyze session token randomness and entropy. Detect patterns, weak PRNGs, and predictable session identifiers.

Tested tool guide Tested browser tools Checked August 16, 2026

What Session Token Entropy Analyzer does, with a checked example

This tool scores a session token's randomness from the character distribution and structure of the text you paste. It reports Shannon entropy in bits per character, the effective alphabet size, how close the token comes to that alphabet's theoretical ceiling, and a set of pattern checks: repeated characters, ascending runs, alternating rhythms, embedded timestamps, and hex or base64 fingerprints. The result users most often misread: a high bits-per-character score describes uniformity, not unpredictability. A token that cycles evenly through its alphabet scores at the ceiling while staying perfectly predictable, so the pattern findings, not the bit count, carry the verdict. A real token never leaves the browser.

Worked example

A concrete input and expected output from the current implementation.

Input

a1b2c3d4e5f6

Expected output

Alphabet: 12 distinct symbols (a-f, 1-6)
Shannon entropy: 3.585 bits per character, 43.0 bits total
Utilization: 100.0% of the alphabet's ceiling (log2(12) = 3.585)
Chi-square vs uniform: 0.0 (all counts exactly even)
Patterns: letter/digit alternation; letter run ascending (a to f); digit run ascending (1 to 6); zero repeated characters
Verdict: weak - structure detected despite a maximal per-character score

Every character appears exactly once, so the frequency distribution is perfectly flat and per-character entropy hits the 3.585 bits/char ceiling for a 12-symbol alphabet (12 x 3.585 = 43.0 bits). The ascending letter and digit subsequences and the strict alternation are what the pattern checks catch: the flat distribution was arranged, not produced by chance, which is why the verdict stays weak.

How the result is produced

1

Entropy measurement

The analyzer infers the alphabet from the characters actually present in the sample, counts occurrences, and applies the Shannon formula H = -sum(p * log2(p)) over relative frequencies. The result is reported per character and multiplied by the token length for total bits, then divided by log2 of the alphabet size to give utilization. Longer tokens yield stabler estimates; short samples are dominated by sampling noise.

2

Pattern and generator checks

Beyond the bit count, the tool scans the raw text for structure: runs of repeated characters, monotonically increasing or decreasing subsequences, strict alternation between letter and digit classes, long numeric stretches that resemble Unix timestamps, and hex or base64 alphabets. Given a batch of tokens it also compares successive values for shared prefixes, fixed offsets, or autocorrelation, which is where sequential and time-derived session identifiers reveal themselves.

Good uses

  • Auditing your own server before launch: paste session cookies or CSRF tokens the framework generated and check whether one token would let an attacker predict the next.
  • Investigating a session hijacking or fixation report: pull a few hundred tokens from access logs and look for incrementing values, shared prefixes, or embedded timestamps.
  • Comparing random sources: generate candidate tokens with Math.random(), a hand-rolled linear congruential generator, and crypto.getRandomValues(), then see which ones the analyzer flags.

Limits and checks

  • The bits-per-character score is not a security certificate. Uniformity over the alphabet says nothing about ordering, and the example above scores at the ceiling while remaining fully predictable. Read the pattern findings first.
  • One short token supports only structural checks. A single sample's frequency counts are sparse, the alphabet estimate is provisional, and no analysis can tell whether a lone value came from a strong or weak generator. Bring a batch.
  • Utilization near 100% is expected for short hex or base64 tokens and says little. A hex string caps at 4 bits per character regardless of generator, and small samples sit close to their own ceiling by chance, so the utilization number only becomes informative on longer samples.

Common questions

It reports 43 bits of entropy. Is my session token secure?

Not because of that number. The bit count measures how evenly characters are spread across the detected alphabet, nothing more; an ordered token can reach the same figure. The pattern findings carry the verdict, and a real assessment needs several dozen tokens from the same generator, because weak sources show up in correlations between successive values, not inside any single value.

Can it tell me which PRNG produced the token?

Usually not by name. It can surface fingerprints a generator leaves behind - sequential counters, timestamp seeds, base64url alphabets, or repeating blocks that reveal a short period - and those can rule specific implementations in or out. But samples are short and two different weak generators can emit indistinguishable tokens, so expect a structural verdict, not an identification.

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

Password Generator

Generate strong, random passwords with customizable length, character sets, and complexity requirements.

Password Strength Checker

Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.

Random String Generator

Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.

QR Code Generator

Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.

QR Code Reader

Scan and decode QR codes from uploaded images or your device camera to extract embedded data.

File Checksum Calculator

Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.