abi.encodePacked of uint256 vs bytes32: 32-Byte Big-Endian Semantics

Two encoding functions are available in Solidity:

• abi.encode(...) is the canonical ABI encoder. Fixed-width types pad to 32 bytes; dynamic types get a length-prefix offset. Used by every call(...) and event log.
• abi.encodePacked(...) is the tight-pack encoder. Each value is written at its own natural byte width with no padding and no length prefix. Used when the developer wants the smallest possible byte sequence — typically for hashing.

For uint256 and bytes32, the natural byte width is identical (32 bytes), so the packed output is identical:

uint256 x = 0x000000000000000000000000000000000000000000000000000000000000002a; // 42

bytes memory a = abi.encodePacked(x);           // 32 bytes, big-endian
bytes memory b = abi.encodePacked(bytes32(x));  // same 32 bytes
// keccak256(a) == keccak256(b) — always.

This is why uint256 and bytes32 are interchangeable inside hash inputs. They occupy the same slot, big-endian.

keccak256(abi.encodePacked(uint256 a, uint256 b))
// 64 bytes — first 32 are `a`, second 32 are `b`. Deterministic, no collision possible.

uint8, uint16, ..., uint256, int* siblings, address (20 bytes), bytes1 through bytes32, and bool (1 byte) all pack at their natural width with no surprises.

keccak256(abi.encodePacked("ab", "c"));  // packs "abc" (3 bytes)
keccak256(abi.encodePacked("a", "bc"));  // packs "abc" (3 bytes) — same hash

Both calls produce identical hash inputs because abi.encodePacked writes string contents without length prefixes. Two different logical inputs collide to the same hash.

This is the production exploit pattern: a signature scheme that hashes abi.encodePacked(user, message) is vulnerable to replay if the attacker can manipulate where user ends and message begins.

Three rules cover the safe usage:

• Use abi.encode, not abi.encodePacked, whenever a dynamic type is involved. abi.encode adds the length prefix and the encoding is unambiguous.
• Use abi.encodePacked only when every input is fixed-width or when collisions are impossible by construction (for example, you control the input completely and never let user data into the pack).
• When you need both performance (tight packing) and safety, separate the dynamic parts with a fixed-width delimiter that the attacker cannot inject. For example, abi.encodePacked(user, bytes1(0x00), message) is collision-resistant if user cannot contain a null byte.

Pair this with the keccak256 hash generator tool and the ABI encoder decoder to test your encoding decisions interactively before committing them to a deployed contract.

Developers pasting solidity abi.encodepacked uint256 bytes32 encoding 32 bytes big endian into Google are usually verifying a hash input mid-implementation. The query phrasing is unusually long because the developer is testing whether the two encodings are equivalent — they typed every fact they thought might matter into the search bar.

The short answer is: yes, equivalent for these two specific types. The longer answer (the one that matters for production) is: stop using abi.encodePacked with any dynamic input.