SHAKE-256 Hash Generator

Understanding SHAKE-256 hashing

SHAKE-256 is an extendable-output function (XOF) belonging to the SHA-3 family, standardized by the National Institute of Standards and Technology (NIST) in FIPS PUB 202. Unlike traditional hash functions such as SHA-256 that produce a fixed-length digest, SHAKE-256 allows the user to specify an arbitrary output length in bits, making it exceptionally flexible for a wide range of cryptographic applications. The "256" in its name refers to its maximum security strength, not the output length. According to the NIST Computer Security Resource Center, the effective preimage and collision resistance also depend on the requested output length.

The Keccak tool demonstrates the original Keccak family that underpins SHAKE-256. Keccak was designed by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche and selected as the winner of the NIST SHA-3 cryptographic hash algorithm competition in 2012 after an extensive public evaluation process involving over 60 submissions from the global cryptographic community. The Keccak team's official website provides comprehensive documentation on the algorithm's design rationale, including the security analysis behind the sponge construction's capacity parameters.

The sponge construction: the technical foundation of SHAKE-256

Unlike older hash functions that rely on the Merkle-Damgård construction (used by SHA-1 and SHA-2), SHAKE-256 is built on the sponge construction, a fundamentally different paradigm. The NIST FIPS 202 standard defines the sponge construction as operating in two distinct phases:

• Absorbing phase: The input message is divided into blocks of 136 bytes (the "bitrate" for SHAKE-256's 1088-bit rate). Each block is XORed into the 1600-bit internal state, which then undergoes 24 rounds of the Keccak-f[1600] permutation. This permutation applies five distinct step mappings: theta (θ), rho (ρ), pi (π), chi (χ), and iota (ι), each designed to maximize diffusion and nonlinearity.
• Squeezing phase: Once all input blocks have been absorbed, the state is read out in 136-byte blocks. For each block read, the state undergoes another 24 rounds of the Keccak-f[1600] permutation before the next block is extracted. This process continues until the requested output length is satisfied.

The sponge construction's defining advantage is that it naturally supports variable-length output without additional padding or mode-of-operation overhead. The capacity parameter for SHAKE-256 is 512 bits, meaning that 512 bits of the internal state are never directly exposed to input or output operations, providing the algorithm's security foundation. According to the Keccak team's sponge construction page, this design also offers inherent resistance to length extension attacks, a known vulnerability in Merkle-Damgård-based hash functions.

Output length control: how XOF differs from fixed-length hashing

The extendable-output property of SHAKE-256 is its most distinguishing feature. On this page, you can select any output length from 8 to 4096 bits, provided it is a multiple of 8 (byte-aligned). This flexibility has important implications:

• Short outputs (8–128 bits): Useful for creating compact identifiers, checksums, or format tags where collision resistance requirements are modest. For example, a 64-bit output can serve as a probabilistic unique identifier in distributed systems.
• Medium outputs (256–512 bits): A 256-bit SHAKE-256 output can offer a similar collision-resistance bound to SHA-256, but the algorithms, outputs, identifiers, and protocol compatibility are different. A 512-bit SHAKE-256 output likewise shares a length with SHA-512 without becoming the same function.
• Long outputs (1024–4096 bits): Useful for test vectors and constructions that explicitly specify long SHAKE-256 output. Output length alone does not turn raw SHAKE-256 into a complete KDF or deterministic random-bit generator.

It is critical to record the requested output length alongside the hash value. For the same input and domain separation, a longer SHAKE-256 output starts with the same prefix as the shorter output, but two values should still be compared only when the same output length, input encoding, and output encoding are expected.

Security properties: collision, preimage, and length extension resistance

SHAKE-256's security guarantees are formally defined in NIST FIPS 202 and are derived from the underlying Keccak sponge construction with a 512-bit capacity. The following table summarizes the security properties:

These security properties make SHAKE-256 suitable for a wide range of applications where traditional fixed-length hash functions would be insufficient or where the flexibility of variable output is beneficial. The NIST SHA-3 project page provides additional details on the security analysis and validation of the SHA-3 family, including the SHAKE variants.

SHA-3 family comparison: SHAKE-256 vs SHAKE-128 vs SHA3-256

The SHA-3 family includes both traditional hash functions (SHA3-224, SHA3-256, SHA3-384, SHA3-512) and XOFs such as SHAKE-128 and SHAKE-256. For a fixed-output comparison, the SHA-256 tool demonstrates the separate SHA-2 algorithm; matching output length does not make SHAKE256-256 a drop-in SHA-256 replacement. The following table highlights the key differences:

The higher capacity of SHAKE-256 (512 bits) compared to SHAKE-128 (256 bits) provides stronger security guarantees at the cost of a slightly lower bitrate (1088 vs 1344 bits per permutation), which means SHAKE-256 is marginally slower for very long inputs. In practice, the performance difference is negligible for most use cases. The Keccak reference paper provides a detailed explanation of the capacity-bitrate trade-off and its impact on security.

Applications of SHAKE-256 in modern cryptography

SHAKE-256 has found adoption across multiple domains in cryptography and information security:

• Protocol and application design: SHAKE-256 can be used in protocols or application-specific constructions that explicitly select an XOF and define the required output length.
• Deterministic byte expansion: The XOF property can expand a fixed input into a repeatable stream of bytes for test vectors or carefully specified cryptographic constructions.
• Post-quantum cryptography: SHAKE functions are used by several post-quantum cryptographic designs, including algorithms derived from CRYSTALS-Kyber and CRYSTALS-Dilithium.
• Integrity verification: Variable-length outputs allow integrity tags to be sized according to the application's security requirements and bandwidth constraints.
• Test vector generation: The ability to produce short and long outputs from the same input makes SHAKE-256 ideal for generating cryptographic test vectors across different output lengths.
• Key derivation constructions: A protocol can incorporate SHAKE-256 into a fully specified KDF with appropriate domain separation and context handling. Raw SHAKE-256 output should not automatically be treated as a complete KDF.

History of SHAKE-256: from Keccak to NIST standardization

The development of SHAKE-256 is closely tied to the history of the SHA-3 competition and the Keccak algorithm:

• 2008–2012, SHA-3 competition: NIST initiated a public competition to develop a new cryptographic hash standard as a successor to SHA-2. Keccak was among 64 initial submissions and underwent three rounds of intensive cryptanalysis by the global research community.
• October 2012, Keccak selected as winner: NIST announced Keccak as the winner of the SHA-3 competition, citing its elegant design, strong security margins, and excellent performance across software and hardware platforms.
• August 2015, NIST FIPS 202 published: NIST standardized SHA-3 and the SHAKE XOFs in FIPS PUB 202, formally defining SHAKE-128 and SHAKE-256 alongside SHA3-224, SHA3-256, SHA3-384, and SHA3-512.
• 2015–present, growing adoption: SHAKE-256 has been incorporated into numerous standards and protocols, including the IETF's Cryptographic Message Syntax (CMS), PKCS, and emerging post-quantum cryptographic schemes.

Output encoding reference: HEX vs Base64

HEX encoding is the default choice for this tool because it is human-readable and easy to compare visually. Base64 is approximately 33% more compact and is preferred for programmatic use where bandwidth or storage efficiency matters. Note that Base64 is case-sensitive, so the case conversion buttons are disabled when Base64 output is selected.

Use case recommendations for SHAKE-256 output lengths

The following table provides practical guidance for selecting the appropriate output length based on common use cases:

Known SHAKE-256 test vector

This reproducible vector checks the tool against independent implementations. Enter abc as UTF-8, choose HEX output, and request 256 bits:

Cross-check the same 32-byte output with one of these independent implementations:

Python:  hashlib.shake_256(b"abc").hexdigest(32)
OpenSSL: printf abc | openssl dgst -shake256 -xoflen 32
Node.js: createHash("shake256", { outputLength: 32 }).update("abc").digest("hex")

Input encoding examples: how byte representation affects the hash output

Understanding how input encoding works is critical for obtaining correct and reproducible SHAKE-256 hash values. The tool interprets the input text as raw bytes according to the selected encoding mode:

• UTF-8 (default): The input string is encoded into bytes using the UTF-8 character encoding. This is the standard encoding for text on the web and is appropriate for most plain-text inputs. For ASCII characters (U+0000 to U+007F), UTF-8 uses one byte per character. For non-ASCII characters (e.g., é, ñ, CJK ideographs), UTF-8 encodes them as multi-byte sequences.
• HEX: The input is interpreted as a hexadecimal string, where each pair of characters (e.g., "a1", "ff") represents one byte. The tool validates that only valid hex characters (0–9, a–f, A–F) are present. If an odd number of hex characters is provided, a leading "0" is automatically prepended.
• Base64: The input is decoded from a Base64-encoded string into raw bytes using the standard Base64 alphabet (A–Z, a–z, 0–9, +, /) with "=" padding. The tool validates the Base64 format and reports an error if the input is not valid Base64.

A common mistake is to assume that the same visible text produces the same hash regardless of encoding. For example, the hex string "48656C6C6F" (which represents "Hello" in ASCII) will produce a completely different hash when interpreted as UTF-8 text rather than as HEX bytes. Always ensure that the input encoding matches the format of your source data.

Advanced configuration tips

• Input encoding discipline: Use UTF-8 for plain text, HEX for hexadecimal bytes, and Base64 only for properly encoded Base64 data. Mixing these encodings will produce unexpected results.
• Output length choice: Start with 512 bits for high-margin examples, then compare shorter and longer byte-aligned outputs as needed. A 256-bit SHAKE-256 output can be useful where a specification explicitly requires it, but it is not interchangeable with SHA-256.
• Validation workflow: Test with short known samples first, compare with trusted libraries when exact matching matters, and record both encoding and output length. Use the "Compare scenarios" feature to save multiple configurations side by side.
• Cross-platform consistency: SHAKE-256 is deterministic and platform-independent. The same input bytes and output length will always produce the same hash, regardless of the operating system, browser, or hardware.

Limitations and cautions

• Client-side processing: Everything runs in the browser using the js-sha3 library. No data is transmitted to any server, which means your input remains private.
• Encoding sensitivity: A wrong input format can produce an error or a different digest than expected. Always verify that the input encoding matches the format of your source data.
• Browser dependency: The page assumes a modern browser with JavaScript enabled. The js-sha3 library is loaded from a CDN and requires network access on first load.
• Educational scope: This page is intended for learning, experiments, and quick format checks rather than full production deployment. For production systems, use audited cryptographic libraries that explicitly support SHAKE-256, such as OpenSSL or Bouncy Castle.

Final tips

1. Start with UTF-8 input and 512 bit HEX output for a high-margin first test.
2. Use HEX and Base64 input modes only when your source value is already encoded that way.
3. Double-check the exact output bit length before comparing against external examples.
4. Use this page for education, experimentation, and quick browser verification.
5. Use audited libraries and secure workflows for critical production needs.

Results are for educational and testing purposes only. Actual outputs depend on the exact bytes represented by the selected input encoding and output settings. For authoritative reference, consult the NIST FIPS 202 standard, the NIST hash function project page, and the Keccak team's official documentation.

Technical reference: NIST FIPS PUB 202. Test outputs were cross-checked against a separate SHAKE-256 implementation. Reviewed by Funifytools for the Cryptography & Hash collection. Last reviewed: July 2026.