With compressed ordinary object pointers enabled in a typical 64-bit HotSpot JVM, a Java object reference is represented using 32 bits.
An ordinary reference on a 64-bit system would normally occupy a 64-bit machine-word-sized pointer. Compressed OOPs reduce that footprint by storing a 32-bit offset rather than a complete native address. The JVM decodes the offset by scaling it—usually around 8-byte object alignment—and adding it to a heap base address.
This saves memory in object headers, reference fields, and arrays of references, which can improve cache use as well as reduce heap consumption. With the usual alignment scheme, a 32-bit offset can address a heap of roughly 32 gigabytes, even though the encoded value itself is only four bytes.
The answer describes HotSpot’s compressed representation, not a universal rule imposed by the Java language. It can depend on the JVM implementation, process width, heap size, and runtime options. Compressed class pointers are related but different: they encode class metadata references, whereas compressed OOPs encode references to Java objects. The feature became broadly available in HotSpot and was enabled by default in common configurations from Java 6 update 23 onward.