WKB (Well-Known Binary)
May 25,2026

GISBox is a one-stop 3D GIS data editing, conversion and publishing platform that supports editing in multiple GIS formats such as OSGB/GEOTIFF/RVT, converting to 3DTiles/Terrain and publishing.

Introduction

WKB (Well-Known Binary) is a binary encoding standard defined by the Open Geospatial Consortium (OGC) for representing geometric objects. It stores spatial features such as points, lines, and polygons as a compact byte stream. Compared to the text‑based WKT format, WKB offers higher storage efficiency and faster transmission and parsing speeds. Its structure typically consists of a 1‑byte byte order marker (0x01 for little‑endian), a 4‑byte geometry type code (e.g., Point = 1, LineString = 2), followed by coordinate data. Coordinates are arranged as IEEE 754 double‑precision floating‑point numbers. WKB is widely used as the underlying storage format for geometry fields in spatial databases such as PostGIS and MySQL.

File Structure

The file structure of WKB follows the OGC Simple Features specification, encoding geometric objects in a compact binary sequence. The structure is described field by field as follows:

Byte order marker (1 byte): The first byte is an unsigned integer. 0x00 indicates big‑endian, 0x01 indicates little‑endian. It determines the parsing order of all subsequent multi‑byte data.
Geometry type code (4 bytes): A 4‑byte unsigned integer immediately following the byte order marker, identifying the type of the geometric object.
SRID identifier (optional, 4 bytes): If the high‑order bit of the type code contains 0x20000000, a 4‑byte unsigned integer representing the Spatial Reference System Identifier (e.g., EPSG:4326) follows the type code.
Length field (4 bytes, only for multi‑element structures): For MultiPoint, MultiLineString, MultiPolygon, and GeometryCollection, a 4‑byte integer specifying the number of child elements follows immediately after the SRID (or after the type code if SRID is absent).
Empty geometry (EMPTY): Represented solely by the type code (e.g., 1 for Point), containing no coordinate data, length field, or SRID. Its structure is: [byte order][type code], totaling 5 bytes.

Pros

High storage efficiency: Compared to the WKT text format, WKB reduces storage redundancy by 40%–60%. It uses IEEE 754 double‑precision floating‑point numbers to compactly encode coordinates, significantly lowering disk and memory usage.
Fast transmission and parsing: The binary format requires no character parsing, making it suitable for high‑frequency read/write scenarios. It is the default storage format for spatial databases such as PostGIS and MySQL.
Strong cross‑platform compatibility: The standardized byte order (0x00/0x01) ensures unambiguous parsing across different operating systems and architectures, and it integrates seamlessly with mainstream GIS toolchains.
Support for complex geometric structures: Fully covers points, lines, polygons, multi‑part objects, and geometry collections. High‑order flags (0x80000000, 0x40000000) extend support for 3D (Z) and measured values (M).
Native database support: Directly supported by major spatial databases (e.g., PostgreSQL/PostGIS, MySQL, Kingbase), allowing participation in spatial function operations without additional conversion.

Cons

Completely unreadable: The binary byte stream cannot be interpreted directly by humans. Debugging requires dedicated tools (e.g., ST_AsBinary(), hex() functions) or GIS software visualization.
Difficult debugging and troubleshooting: When data is corrupted (e.g., coordinate errors, byte order mismatches), it is hard to locate the issue without byte‑by‑byte parsing, increasing development and maintenance costs.
Lack of embedded metadata: Does not include coordinate system names, units, projection parameters, or other descriptive information. SRID is only an integer identifier (e.g., 4326), relying on external metadata management.
Version and extension compatibility risks: 3D/measurement extensions rely on high‑order flags. Different systems may have inconsistent support for extension types like 0xC0000001, leading to migration failures (e.g., PostGIS → Dameng).
Explicit conversion required for interoperability: When interacting with text formats such as WKT and GeoJSON, functions (e.g., ST_GeomFromWKB(), ST_AsText()) must be called, increasing SQL complexity and performance overhead.

Application Scenario

WKB is widely used for underlying storage in spatial databases and efficient data exchange. As the default geometry encoding format in systems like PostGIS, MySQL, and Kingbase, it enables fast serialization and deserialization of spatial features (points, lines, polygons, etc.) in GIS. It supports high‑frequency operations such as spatial index construction, proximity queries, and topological analysis. In distributed geographic data transmission, map service tile preprocessing, and mobile GIS applications, its compact binary structure significantly reduces network bandwidth and memory overhead, making WKB a critical bridge connecting databases, GIS engines, and front‑end rendering modules in spatial data interoperability.