ec_point_formats
ec_point_formats lists elliptic curve point formats, a TLS 1.2 leftover that every measured client still sends.
What it is
ec_point_formats (extension 11) was introduced with elliptic curve cryptography for TLS and is now specified in RFC 8422. It tells the server which encodings of elliptic curve points the client understands, originally uncompressed and two compressed formats.
RFC 8422 deprecated the compressed formats, so a modern client only needs to say uncompressed. TLS 1.3 does not use the extension at all, because the point format is fixed by each group.
Clients still send it because they keep supporting TLS 1.2 servers, where RFC 8422 still defines it.
Point formats describe how a public key on an elliptic curve is written down as bytes. Uncompressed points store both coordinates; compressed points store one coordinate and a sign bit, which saves bytes but needs extra computation. The extension mostly exists today so older TLS 1.2 servers keep accepting elliptic curve suites.
Who sends it
Measured on 2026-10-25 against our own test server: sent by 12 of 12 clients. Position counts from 1 and ignores GREASE values.
Why it matters for fingerprinting
Every measured client sends it, and JA3 gives its content a field of its own, the last field of the JA3 string. Chrome, curl_cffi, curl-impersonate, Go net/http and macOS curl send only uncompressed (0). Python requests, httpx, Node.js fetch, Guzzle and Debian curl, all built on OpenSSL, still list all three formats (0-1-2), so a JA3 ending in 0-1-2 points straight at an OpenSSL client.
Check whether your client sends it
Open the test from your browser, or call it from your script, and look for ec_point_formats in the TLS details.
Run the TLS fingerprint test