Actually, WASM32 usually runs in a 64-bit browser, so it can utilize most of the 64-bit instructions and general purpose registers. The problem is it's much harder to ensure that 64-bit pointer don't access browser critical data structures such as stack or heap contents. At least for WASM32, the pointer arithmetic is easily forced to be 32-bit in natively running JIT-ed code without dramatic performance loses. So, it's guaranteed that the WASM32 module won't access anything further than 4 or 8GiB (4GiB + 4GiB, when doing more complicated effective memory addressing instructions), thus, it's easy to cage a 4GiB memory block and surround it with guard buffers of comparable size inside a 64-bit virtual address space. With WASM64 you can't do this optimization because 64-bit pointers easily access your browser's memory, you have to add a lot of runtime bound checks if the compiler static checker can't guarantee landing inside the safe address range.