Random Token Generator
Hasilkan random tokens yang aman secara kriptografis.
Cara menggunakan Random Token Generator
Masukkan Token Length
Tentukan panjang token yang ingin Anda hasilkan. Anda dapat memilih dari berbagai panjang untuk memenuhi kebutuhan Anda.
Pilih Jenis Token
Pilih jenis token yang ingin Anda buat, seperti alphanumeric atau hexadecimal. Ini akan menentukan karakter yang digunakan dalam token.
Buat Token
Klik tombol 'Generate Token' untuk membuat random token yang aman secara kriptografi. Anda dapat menyalin dan menempel token ke dalam aplikasi atau sistem Anda.
Alat Terkait
Random token generator online: cryptographically secure tokens in your browser
Random token generator online: cryptographically secure tokens in your browser
Generate cryptographically secure random tokens for API keys, session tokens, CSRF tokens, and webhook secrets with the random token generator at ToolHQ. Choose your length and output format (hex, base64, alphanumeric). Generated entirely in your browser, no token is ever transmitted.
A random token is a string of cryptographically random bytes used as a secret identifier. Unlike a UUID, which has a specific structure and purpose (unique identifier), a token is purely random data encoded for use as a key or secret. Tokens appear as API keys, session identifiers, CSRF tokens, webhook signing secrets, and one-time reset codes. The randomness must come from a cryptographically secure source, or the tokens can be predicted by an attacker.
Key Takeaways
- Use cryptographically secure random tokens, not Math.random(), for security-sensitive strings
- 16 bytes (32 hex characters) = 128-bit security; 32 bytes (64 hex characters) = 256-bit security
- Common formats: hex (lowercase a-f and 0-9), base64 (shorter, more characters per byte), URL-safe base64
- Use cases: API keys, session tokens, CSRF tokens, webhook secrets, OAuth state parameters
- Generated entirely in your browser, no token is ever transmitted to any server
Cryptographic randomness vs. pseudo-randomness
Not all random number generators are equal. The distinction matters for security.
Math.random() (JavaScript's built-in random function) produces pseudo-random numbers. It generates values that look random and pass basic statistical tests, but the output is seeded from a predictable state. An attacker who knows the seed or can observe enough output values can predict future values. Using Math.random() to generate security tokens is a well-known vulnerability.
crypto.getRandomValues() is the browser's cryptographically secure random number generator. It draws from the operating system's entropy pool, which is seeded from hardware events (mouse movements, keystroke timing, hardware interrupts) that are genuinely unpredictable. Predicting the output is computationally infeasible.
ToolHQ's random token generator uses the Web Crypto API's crypto.getRandomValues() function to generate tokens. This is the same source of randomness used by browsers for TLS key generation and other cryptographic operations.
The difference in practice: an API key generated with Math.random() might be guessable by an attacker who can observe several of your other API keys. An API key generated with crypto.getRandomValues() with 128-bit entropy cannot be guessed regardless of how many other keys the attacker has seen.
Token length and security level
The security of a random token comes from the number of possible values it could take. More bytes = more possible values = harder to guess by brute force.
| Bytes | Hex characters | Base64 characters | Security bits | Typical use |
|---|---|---|---|---|
| 8 | 16 | 11 | 64-bit | Short-lived codes (not recommended for secrets) |
| 16 | 32 | 22 | 128-bit | Session tokens, CSRF tokens, API keys |
| 32 | 64 | 43 | 256-bit | High-security secrets, signing keys, master keys |
| 48 | 96 | 64 | 384-bit | Long-lived signing secrets, OAuth secrets |
128 bits (16 bytes) is sufficient security for most application tokens. At 128 bits of entropy, brute-forcing the token space is beyond the capability of any current or foreseeable computing system.
256 bits (32 bytes) is used for high-security applications where tokens are long-lived or where the cost of a compromise is very high. JWT signing secrets, OAuth client secrets, and encryption keys are commonly 256-bit.
Use at least 16 bytes (128-bit) for any security-sensitive token. For persistent secrets that protect high-value resources, use 32 bytes (256-bit).
Token output formats
Different contexts require different token formats:
Hex encodes each byte as two hexadecimal characters (0-9, a-f). A 16-byte token becomes 32 hex characters. Hex is universally safe in URLs, headers, and database fields. It is the most common format for API keys and session tokens.
Base64 encodes every 3 bytes as 4 characters using A-Z, a-z, 0-9, +, and /. A 16-byte token becomes approximately 22 base64 characters. Base64 is more compact than hex but the + and / characters require URL encoding in query strings.
URL-safe base64 replaces + with - and / with _ making the output safe in URLs and HTTP headers without encoding. This is the format used in JWTs (JSON Web Tokens) and many OAuth implementations.
Alphanumeric restricts output to A-Z, a-z, 0-9. Slightly less entropy per character than base64 but readable and safe in any context that accepts alphanumeric strings.
Common use cases for random tokens
API keys: Authentication credentials that client applications include in API requests. Use 32 hex characters (16 bytes) as a minimum. Store the hash of the API key in your database rather than the key itself.
Session tokens: Assigned to users when they log in and stored in a cookie or localStorage. Used to identify authenticated sessions server-side. Use 32 hex characters minimum; many frameworks default to 32 bytes (64 hex characters).
CSRF tokens: Cross-Site Request Forgery tokens are embedded in forms and verified server-side to confirm that form submissions originate from your own pages rather than attacker-controlled pages. Use 16-32 bytes.
Webhook secrets: Used to sign webhook payloads so the receiving endpoint can verify the payload came from the expected source. GitHub, Stripe, and most modern webhook providers use HMAC-SHA256 signatures with a shared secret. Generate a 32-byte hex secret.
OAuth state parameter: A random value passed in the OAuth authorization request and verified when the callback arrives. Prevents CSRF attacks on OAuth flows. Use 16-32 bytes.
Password reset tokens: One-time tokens sent by email to authenticate a password reset request. Use 32 bytes and expire them after 15-30 minutes.
Mini-story: A backend developer was building an API for a mobile application. The first version used a sequential integer as the API key (user ID 1 gets key "1", user ID 2 gets key "2"). A security review immediately flagged this: any user could guess other users' API keys by incrementing the value. The developer replaced the integer keys with 32-byte hex tokens generated using crypto.getRandomValues() via ToolHQ's random token generator. The new keys were unique, unpredictable, and immune to enumeration.
Generate your token now at ToolHQ's random token generator.
How to generate a token step by step
- Open the tool. Visit ToolHQ's random token generator.
- Choose byte length. Select 16 bytes for standard security (128-bit) or 32 bytes for high security (256-bit).
- Choose format. Select hex, base64, URL-safe base64, or alphanumeric based on where you will use the token.
- Generate. Click "Generate". The token is produced using crypto.getRandomValues() in your browser.
- Copy and use immediately. Tokens are generated fresh each time. Copy it into your application, configuration file, or secret manager immediately. Treat this token as a secret and do not share it.
Frequently asked questions
Is a random token the same as a UUID? A UUID (Universally Unique Identifier) has a specific structured format and is designed to be globally unique. A random token is purely random bytes with no imposed structure. Both can serve as unique identifiers, but tokens are preferred for security-sensitive uses because they have no predictable structure and no metadata embedded in them.
Can I use a random token as a JWT secret? Yes. A JWT signing secret should be a cryptographically random string of at least 256 bits (32 bytes). Generate a 32-byte token in hex or base64 and use it as your JWT_SECRET environment variable.
How do I store API keys securely? Never store the raw API key in your database. Hash it with a fast hash (SHA-256) and store only the hash. When the client presents the key, hash it and compare to the stored hash. This way, a database breach does not expose usable API keys.
What makes a token "cryptographically secure"? A cryptographically secure token is generated from a source of entropy that cannot be predicted or reproduced: hardware-level randomness. crypto.getRandomValues() meets this bar. Math.random() does not.
The short version
Random tokens are the building blocks of application security: API keys, session identifiers, CSRF tokens, and webhook secrets all rely on unpredictable random bytes. The randomness must come from a cryptographically secure source (crypto.getRandomValues(), not Math.random()); otherwise, the tokens can be guessed. Use at least 16 bytes (128-bit) for any security-sensitive token, 32 bytes for long-lived or high-value secrets. ToolHQ's random token generator uses the browser's cryptographic random source and produces tokens in hex, base64, URL-safe base64, or alphanumeric format, all without transmitting anything to a server.
Generate a secure random token at ToolHQ.
Related tools: UUID generator | Password generator | Hash generator | Encryption tool