Pseudorandom vs True Random: How to Tell the Difference

When people talk about random numbers, very different things often get lumped together under the single word random, so the discussion quickly drifts. A sequence generated by calculation such as Math.random() and a sequence derived from physical phenomena such as thermal noise or clock jitter can both look nicely scattered at a glance.

In practice, however, leaving that distinction vague leads to mistakes such as these:

• you want reproducibility in a simulation, but the result changes every run
• you generate password-reset tokens with random numbers that are easy to predict
• you assume that passing a statistical test means “this must be true random”
• or, in the opposite direction, you hear pseudo and assume everything is unsafe

This article organizes what pseudorandom means, what true random means, and how to tell them apart in a way that is easier to use in real engineering decisions. The main focus is not on the surface appearance of the output, but on the construction of the generator.

The discussion here is organized based on NIST, IETF, OS, and official language documentation that could be confirmed as of April 2026.

Contents

1. Table of Contents
2. 1. The short answer
3. 2. What this article means by “pseudorandom” and “true random”
4. 3. First, a one-page picture
   • 3.1. Relationship diagram
   • 3.2. The shortest terminology summary
5. 4. What pseudorandom means
   • 4.1. In one sentence
   • 4.2. Ordinary PRNGs and CSPRNGs should be discussed separately
6. 5. What true random means
   • 5.1. In one sentence
   • 5.2. Even physical randomness is not always used raw
7. 6. What is different
   • 6.1. Source of generation
   • 6.2. Reproducibility
   • 6.3. Predictability
   • 6.4. Speed and operational constraints
8. 7. How to tell them apart
   • 7.1. From output alone, you generally cannot fully distinguish them
   • 7.2. First, inspect the design of the generator
   • 7.3. Next, use statistical testing to look for obvious defects
   • 7.4. For security use, evaluate from the attacker’s point of view
9. 8. Which one should be used for which purpose
10. 9. Common misconceptions
    • 9.1. If it passes statistical tests, it must be true random
    • 9.2. If it is true random, it is always safe
    • 9.3. All pseudorandom numbers are dangerous
    • 9.4. For security use, you must directly use raw physical randomness and nothing else
    • 9.5. random or Math.random() spreads values out enough, so it is fine for tokens
11. 10. A practical decision table for when you are unsure
12. 11. Summary
13. 12. References

Table of Contents

1. The short answer
2. What this article means by “pseudorandom” and “true random”
3. First, a one-page picture
   • 3.1. Relationship diagram
   • 3.2. The shortest terminology summary
4. What pseudorandom means
   • 4.1. In one sentence
   • 4.2. Ordinary PRNGs and CSPRNGs should be discussed separately
5. What true random means
   • 5.1. In one sentence
   • 5.2. Even physical randomness is not always used raw
6. What is different
   • 6.1. Source of generation
   • 6.2. Reproducibility
   • 6.3. Predictability
   • 6.4. Speed and operational constraints
7. How to tell them apart
   • 7.1. From output alone, you generally cannot fully distinguish them
   • 7.2. First, inspect the design of the generator
   • 7.3. Next, use statistical testing to look for obvious defects
   • 7.4. For security use, evaluate from the attacker’s point of view
8. Which one should be used for which purpose
9. Common misconceptions
10. A practical decision table for when you are unsure
11. Summary
12. References

1. The short answer

To start with a deliberately rough but practical summary:

• pseudorandom numbers are sequences generated deterministically from internal state and an algorithm
• true random numbers are sequences whose entropy source comes from physical phenomena such as thermal noise or jitter
• however, many secure random-number APIs used in practice do not return raw physical randomness directly, but values from a DRBG / CSPRNG seeded from an entropy source
• so you cannot distinguish them just by asking whether the output “looks random”; what you need to inspect is the generator design, how seed enters it, reseeding, and health tests
• for simulations and reproducible testing, the reproducibility of pseudorandom numbers is a strength
• for security-sensitive uses such as keys, tokens, and nonces, the default should be secure random APIs provided by the OS or the language runtime

In practice, it helps to separate these three questions first:

1. Is this about an ordinary PRNG?
2. Is this about a cryptographic PRNG / CSPRNG / DRBG?
3. Is this about an NRBG / TRNG backed by a physical entropy source?

2. What this article means by “pseudorandom” and “true random”

In this topic, the word random is too broad on its own, so it helps to pin down the meaning first.

• Pseudorandom numbers (PRNGs): generators that produce a sequence deterministically from a seed and internal state. Under the same conditions, they produce the same sequence.
• Cryptographically secure pseudorandom numbers (CSPRNG / DRBG): a kind of pseudorandom generator designed with unpredictability in mind. NIST SP 800-90A defines this as a deterministic random bit generator.
• True random numbers: in everyday language this usually means physical random numbers or true RNGs. In NIST terminology, NRBG (non-deterministic random bit generator) is the closest term. It describes a generator that continuously relies on an entropy source and, under normal operation, produces full-entropy output.

The key point here is that pseudorandom is not the same thing as unsafe.

For example, a fast PRNG such as a linear congruential generator or a simple xorshift and a CSPRNG such as CTR_DRBG or HMAC_DRBG are both deterministic, but they mean very different things from a security perspective.

3. First, a one-page picture

3.1. Relationship diagram

It is often fastest to look at the conceptual relationship in one picture.

flowchart LR
    NOISE["Physical phenomena<br/>thermal noise, jitter, etc."] --> ENT["Entropy source"]
    ENT --> SEED["seed / reseed"]
    SEED --> DRBG["DRBG / CSPRNG<br/>expands random bits at high speed"]
    DRBG --> API["Random values returned by the OS / library"]

    STATE["Internal state + formula"] --> PRNG["Ordinary PRNG"]
    PRNG --> OUT["A sequence that looks random"]

The important point is that the output of a secure random-number API used by an application is slightly different from both the ordinary PRNG on the right and the raw physical noise on the left.

In many implementations, the entropy source on the left is used for seed / reseed, and then a DRBG / CSPRNG expands that into values quickly. NIST SP 800-90B and 800-90C are precisely the documents that organize this entropy source + deterministic generator construction.

3.2. The shortest terminology summary

If you want the shortest possible memory aid:

• an ordinary PRNG is randomness you can reproduce
• a CSPRNG is randomness that is still reproducible in principle, but designed to be hard to predict from the outside
• true random numbers are randomness extracted from physical phenomena

4. What pseudorandom means

4.1. In one sentence

Pseudorandom numbers are produced by computation, updating internal state to generate a sequence that looks random.

If you start with the same seed, use the same algorithm, and draw the same number of values, you get the same sequence. That can look like a weakness, but in simulation, testing, and debugging it is often a major advantage.

Because the result is reproducible, you can say things like this seed reproduces the bug or I want to compare today's result against yesterday's result again.

4.2. Ordinary PRNGs and CSPRNGs should be discussed separately

This is where people get confused most often. Pseudorandom = fake = should never be used is wrong.

NIST SP 800-90A defines deterministic random bit generators built on top of hash functions or block ciphers. In other words, a large part of the random generation used in cryptographic systems is also deterministic.

The real difference is not mere random-looking behavior, but unpredictability from the attacker’s perspective.

• Ordinary PRNG
  • fast
  • easy to reproduce
  • easier to predict if the internal state or seed leaks
• CSPRNG / DRBG
  • also deterministic
  • but designed so that outputs are hard to predict as long as the internal state remains unknown
  • the right choice for security use

So if you judge safety only by asking whether something is pseudorandom, you will usually get it wrong. What matters is which kind of pseudorandom generator it is.

5. What true random means

5.1. In one sentence

True random numbers are derived from physical uncertainty such as thermal noise, oscillator jitter, avalanche noise, or quantum phenomena.

In everyday language these are often called physical random numbers or true random numbers. In NIST terminology, NRBG is the closest term: a generator that accesses an entropy source continuously and, as long as it operates normally, produces full-entropy output.

5.2. Even physical randomness is not always used raw

This point also matters. Just because the source is physically random does not mean the raw measured values are passed straight to the application.

Physical sources come with practical difficulties such as:

• bias
• sensitivity to temperature, power conditions, failures, and aging
• raw output rates that may not be especially high
• failures that are hard to notice without health checks

For that reason, NIST SP 800-90B emphasizes entropy-source design principles, min-entropy estimation, validation tests, and health testing. In complete implementations, the whole system is often structured as entropy source + DRBG, as in NIST SP 800-90C.

In other words, true random is not some mystical raw substance. It is something handled together with physical sources, evaluation, monitoring, and post-processing.

6. What is different

The difference between random generators cannot be organized just by asking whether the output looks random. At a minimum, it helps to compare them on these four axes.

6.1. Source of generation

• pseudorandom: algorithm and internal state
• true random: physical entropy source

This is the most fundamental difference.

6.2. Reproducibility

• pseudorandom: reproducible with the same seed
• true random: even under the same conditions, the same sequence is hard to reproduce

Reproducibility is a strength in testing and can be a weakness in things like lotteries.

6.3. Predictability

• ordinary PRNG: if the seed or internal state can be inferred, future values may become fairly predictable
• CSPRNG: designed so that future values remain hard to predict as long as internal state is protected
• true random: difficult to predict if the physical source is healthy, but sensor failures and design mistakes are a separate problem

For security, this axis matters the most. The visual spread of the output matters less than whether the next value can be guessed.

6.4. Speed and operational constraints

• pseudorandom: fast, stable, and easy to implement
• true random: requires entropy collection and monitoring, which brings speed and implementation constraints

That is why real production systems are rarely a simple choice between only true random and only pseudorandom. In practice, a CSPRNG seeded by physical entropy is usually the most realistic answer.

7. How to tell them apart

7.1. From output alone, you generally cannot fully distinguish them

This is the single most important answer. If all you have is a finite output sequence, you cannot prove that this is true random.

The reason is simple: for any finite sequence you observe, it is always possible to write a deterministic program that outputs exactly that sequence. In the extreme case, the sequence can simply be embedded in an array or ROM and returned one value at a time.

So you cannot say it looks natural, therefore it is true random. NIST SP 800-22 also states that statistical testing is only a first step and does not, by itself, absolutely prove generator validity.

Looked at from the other side, a good CSPRNG is intentionally designed to be difficult to distinguish from its output alone. In that sense, hard to distinguish is itself part of the design goal.

7.2. First, inspect the design of the generator

To distinguish them in practice, the design matters more than the surface appearance of the output. Check things like:

• What generation algorithm is used?
  • a simple PRNG, or a DRBG / CSPRNG?
• Where does the seed come from?
  • a fixed seed, current time, PID, or similar?
  • or the OS entropy source?
• Is there reseeding?
  • seed only once at startup and never again?
  • or reseed during operation as well?
• Is the entropy source validated?
  • min-entropy estimation
  • health tests
  • fault detection
• Which API is used?
  • a custom implementation?
  • or a standard OS / language API?

With that lens, many cases become distinguishable enough for engineering decisions:

• fixing the seed always reproduces the same sequence -> pseudorandom
• there is a physical entropy source and the design assumes validation / health testing -> a design with a true-random source
• it calls the OS secure RNG API -> in many cases a hybrid of physical entropy + CSPRNG

7.3. Next, use statistical testing to look for obvious defects

Statistical testing is not unnecessary. It is important. But its role is closer to defect detection than proof.

Typical things you look at include:

• bias in zeros and ones
• run bias
• periodicity
• correlation
• approximate entropy
• linear complexity

NIST SP 800-22 and, in Japan, the CRYPTREC minimum random-number test set are commonly referenced. They are useful for checking whether a sequence shows suspicious bias or structure.

However, passing those tests still does not prove this is true random. A well-designed CSPRNG can pass them just fine, and a physical random source can fail them if a sensor is biased or broken.

A practical interpretation is:

• pass: no glaring defect is easy to see at first glance
• fail: something is likely wrong
• therefore proven to be true random: that conclusion does not follow

7.4. For security use, evaluate from the attacker’s point of view

For uses such as password-reset tokens, session IDs, nonces, or key generation, the question is it true random? is still not enough.

The real question is whether an attacker can predict the next value.

For example:

• the seed is based only on the current time
• it mixes in only a process ID or sequence number
• it is a custom implementation with no serious evaluation of seed quality
• a random-style API is being reused for a security-sensitive purpose

None of those problems is prevented just because the output looks random enough.

IPA also recommends understanding the available security APIs and existing libraries instead of casually building a custom generator. Python explicitly says to prefer the secrets module over random for security purposes. In Java, that role is served by SecureRandom.

In the end, for security the more important question is not pseudorandom or true random, but are you using safe seed / entropy and a safe API?

8. Which one should be used for which purpose

At the implementation level, these choices are usually safe defaults:

• Windows native: BCryptGenRandom
• .NET: System.Security.Cryptography.RandomNumberGenerator
• Linux: getrandom()
• Python: secrets
• Java: SecureRandom

Microsoft Learn explains that Windows BCryptGenRandom uses a default provider conforming to NIST SP 800-90 CTR_DRBG. Linux getrandom() is documented as suitable for cryptographic purposes. .NET RandomNumberGenerator, Python secrets, and Java SecureRandom are likewise APIs intended for security-sensitive randomness.

9. Common misconceptions

9.1. If it passes statistical tests, it must be true random

No. At most, that means there is no obvious bias that stands out immediately.

9.2. If it is true random, it is always safe

No. Physical-source failure, bias, implementation defects, and missing health tests can all degrade quality.

9.3. All pseudorandom numbers are dangerous

No. CSPRNGs / DRBGs are actually the core of many secure random-number APIs used in practice.

9.4. For security use, you must directly use raw physical randomness and nothing else

Not necessarily. In practice, the usual construction is a combination of a physical entropy source and a CSPRNG.

9.5. random or Math.random() spreads values out enough, so it is fine for tokens

That confuses two different questions. Visual spread and unpredictability against an attacker are not the same thing.

10. A practical decision table for when you are unsure

When in doubt, this order of questions is usually enough:

1. Do you need to reproduce the same result?
   • yes -> ordinary PRNG
   • no -> continue
2. Would it be a problem if an attacker could predict it?
   • yes -> standard OS / language secure RNG
   • no -> choose based on quality requirements and speed
3. Do you need accountability or auditability for the randomness source itself?
   • yes -> consider a physical random source or a certified service
4. Do you want to implement it yourself?
   • that instinct is understandable, but RNGs are easy to get wrong, so start with the standard API first

In this order, decisions usually become much faster than treating the problem as nothing more than a binary choice between pseudo and true.

11. Summary

If you want the roughest but still practically useful summary of the difference between pseudorandom and true random, it is this:

• pseudorandom numbers are generated by computation
• true random numbers derive entropy from physical phenomena
• but in real secure random-number APIs, the main actor is usually the middle layer: entropy source + CSPRNG

So what matters is not the appearance, but the construction.

• you cannot determine from output alone whether something is true random
• statistical tests help detect defects, but they do not prove authenticity
• in security, the real question is whether it can be predicted
• if you need reproducibility, use a PRNG; if you need unpredictability, use the standard secure RNG from the OS or language runtime

Framed that way, you can get out of the unhelpful argument over whether pseudorandom numbers are fake.

12. References

1. NIST SP 800-90A Rev. 1: Recommendation for Random Number Generation Using Deterministic Random Bit Generators
   The foundational document for deterministic random bit generators.

2. NIST SP 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation
   Organizes the ideas behind entropy sources, validation, and health testing.

3. NIST SP 800-90C: Recommendation for Random Bit Generator (RBG) Constructions
   Organizes entropy source + DRBG constructions.

4. NIST SP 800-22 Rev. 1a: A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications
   Explains the role of statistical testing. The important point is that testing is a first step, not proof.

5. NIST Glossary: Non-deterministic Random Bit Generator (NRBG)
   Useful for checking the NIST term closest to true random.

6. RFC 4086: Randomness Requirements for Security
   Organizes the cautions around randomness and entropy sources for security use.

7. Microsoft Learn: BCryptGenRandom function
   Explains the Windows secure RNG API and the default provider’s CTR_DRBG.

8. Linux man page: getrandom(2)
   The Linux random API suitable for cryptographic purposes.

9. Microsoft Learn: RandomNumberGenerator class
   The .NET API for cryptographically strong random numbers.

10. Python documentation: secrets — Generate secure random numbers for managing secrets
    The basic reference for security-sensitive randomness in Python.

11. Oracle Java Documentation: SecureRandom
    Summarizes Java’s secure RNG and its treatment of seed / entropy.

12. IPA: Chapter 3, Section 3. Hard-to-break cryptography and the use of pseudorandom numbers
    A Japanese reference that organizes the importance of seeds, statistical testing, and API usage.