Geometry format size comparison, measured

“Binary is smaller” is only half true

The intuition that binary beats text is real for high-precision coordinates and wrong almost everywhere else. WKB spends a fixed 16 bytes per vertex — two 8-byte doubles — no matter how many decimals you actually wrote. Text spends roughly one character per digit. So at low precision, text is already competitive: a 2-decimal point in WKT is 19 characters versus 21 raw bytes of WKB, and the 4-decimal polygon below ties them (112 characters of WKT against 109 bytes of WKB) while halving hex-encoded WKB. WKB only wins clearly at full double precision — around 15+ significant digits — where every one of those 16 fixed bytes is carrying information.

Sample 2 — the same point, but 6 decimals

Input: POINT (-87.650052 41.850437) — sub-decimetre precision. Adding four decimals shows exactly which formats are variable-width and which are fixed. WKT grows by 8 characters to 27, and GeoJSON by the same 8 to 53 — text pays per digit. Raw WKB stays 21 bytes and TWKB stays 10 bytes, because doubles (and TWKB’s declared precision) are fixed-width. And polyline5/6, geohash, S2 and H3 are unchanged: they are fixed-size by design, which is the whole trade — you buy a small, predictable footprint by giving up the ability to store arbitrary precision.

The hex tax

WKB and TWKB are binary. A binary format is only compact while it stays binary — a native bytea / BLOB column, or a wire protocol. The instant it has to travel through JSON, a URL, an XML attribute, or a text column, it gets hex-encoded and every byte becomes two characters. In every single sample above, hex-encoded WKB was the largest encoding — bigger than the self-describing GeoJSON it is supposed to beat. If your transport is text, “compact binary WKB” is usually the worst thing you can reach for. Store WKB as real bytes or don’t use it.

TWKB is the real compact binary

TWKB — Tiny WKB — is what people think WKB is. It combines three ideas: variable-length integers (small numbers take fewer bytes), delta encoding (each vertex stored as an offset from the previous one), and a declared precision so it never stores digits you didn’t ask for. The result was 10 bytes for a point, 32 for the polygon, and 89 bytes for the 40-point route — 7.3× smaller than WKB and 10.6× smaller than GeoJSON on that route. Even hex-encoded, TWKB beat every text format except polyline5. The catch is tooling: TWKB is well supported in the PostGIS/GEOS world but far less ubiquitous than WKB or GeoJSON.

Delta encoding rewards dense paths

Encoded polylines and TWKB share a superpower: their cost scales with the spacing between points, not with the magnitude of the coordinates. Storing “+30 metres east” takes a couple of characters whether you are in Chicago or Christchurch. On the 40-point route that meant 3.7 characters per point for polyline5 versus ~21 for raw text. Precision is nearly free, too: polyline6 gives you 10× the resolution of polyline5 for only 13% more size, because the deltas dominate the encoding, not the extra digit. Two caveats keep this honest — it is lossy (coordinates are rounded to the declared precision) and it only works for points and paths, never polygons with holes.

How to read an encoded polyline

Each point is stored as a delta from the previous point, that delta is zig-zag encoded (so small negative numbers stay small), split into 5-bit chunks, and each chunk is mapped to a printable ASCII character. Close-together points produce tiny deltas which produce 2–4 characters per point; the very first point is absolute and therefore the most expensive one in the whole string. That is why a dense, smooth GPS track compresses so well and a sparse set of far-flung points does not.

Cell IDs buy size by answering a different question

A geohash, S2 token, or H3 index is the smallest possible way to say “where”, because it doesn’t store a coordinate at all — it stores which cell. Geohash is ~9 characters for roughly ±2.4 m; an S2 token is variable length up to 16 characters (trailing zeros truncate, which is why the sample point’s token was only 10); H3 is a fixed 15-character hex string. The trade is right there in Sample 2: four extra decimals changed the WKT, polyline, geohash and S2, but the H3 index was byte-for-byte identical — a cell ID answers “which cell contains this?”, not “exactly where is this?”. And a cell is one point: turning a polygon into cells means a cover that can explode into hundreds of IDs, so “n/a” in the polygon table above is the honest answer, not a small number.

GeoJSON is the biggest in every test — on purpose

GeoJSON came out largest in every sample, and that is the price of what it buys: it is self-describing, human-readable, and parseable by essentially every tool and language without a schema. That makes it the right default for interchange — handing geometry to a system you don’t control — and the wrong default for storage at scale or for URL state, where its repeated keys and brackets are pure overhead. Use it at your boundaries, not in your hot path.

The honest caveat: gzip narrows the gap

Every number on this page is uncompressed size, and that matters because compression changes the story for some use cases. GeoJSON’s repetitive structure gzips and brotlis extremely well, so on a compressed HTTP response the difference between formats shrinks a lot — if bytes-on-an-already-compressed-wire is your only concern, don’t over-optimise. But compression does not help the cases where these gaps bite: URL and hash-fragment state (never compressed), primary keys and spatial-index columns, in-memory arrays, and per-row cost across billions of rows. This comparison matters most for storage, URLs, and memory — say so, and choose accordingly.