SEC 1 §2.3.3 definiert die fast überall verwendeten Octet Strings: unkomprimiert 0x04 ‖ x ‖ y (65 Byte für P-256 und secp256k1, 97 für P-384, 133 für P-521) und komprimiert 0x02 ‖ x oder 0x03 ‖ x, wobei das Präfix die Parität von y angibt (33, 49 und 67 Byte). Beim Dekodieren eines komprimierten Punkts wird die Kurvengleichung nach y aufgelöst, und ein Decoder muss ein x ablehnen, zu dem es kein gültiges y gibt.
Welche Form dir begegnet, hängt vom Ökosystem ab: SubjectPublicKeyInfo in X.509 enthält fast immer unkomprimierte Punkte (RFC 5480 verlangt ihre Unterstützung und macht komprimierte optional), der Import raw von WebCrypto akzeptiert in modernen Browsern beide Formen für ECDSA-Schlüssel, Bitcoin verwendet seit etwa 2012 komprimierte Schlüssel mit 33 Byte, und Ethereum leitet Adressen aus den 64 Byte von x ‖ y ohne das Präfix 0x04 ab. JWKs enthalten immer getrennte Felder x und y.
Edwards- und Montgomery-Kodierungen sind schon konstruktionsbedingt komprimiert: Ein öffentlicher Schlüssel für Ed25519 ist die 32 Byte lange y-Koordinate mit dem Vorzeichen von x im obersten Bit, und X25519 überträgt nur u. Eine Verwechslung von 33-Byte- und 65-Byte-Schlüsseln ist eine häufige Ursache der Fehler „invalid public key“ und „point is not on the curve“.