What H3 is
H3 is a discrete global grid system developed by Uber. It projects a regular icosahedron (20 triangular faces) onto the sphere using a gnomonic projection per face, then subdivides each face hierarchically to produce a grid of predominantly hexagonal cells at 16 resolutions, numbered 0 (coarsest) through 15 (finest). This knowledge base treats H3 as the default interoperability grid for advertising execution elsewhere, but this page describes H3 strictly as a generic cell system, on the same terms as S2 and Geohash — without assuming its properties are universal (see cell-system-comparison).
Hierarchy: aperture 7
H3's subdivision scheme is "aperture 7": each cell at resolution N is covered by approximately 7 cells at resolution N+1. This is a logical, index-arithmetic relationship, not an exact geometric tiling — a parent hexagon's true boundary and the union of its 7 child cells' true boundaries are close but not identical, because the aperture-7 subdivision is not an exact area-7 partition of a hexagon. This is the single most important caveat distinguishing H3 from S2: S2's quad hierarchy gives exact geometric containment (4 children exactly tile their parent), while H3's aperture-7 hierarchy does not. Treating an H3 parent cell as if it exactly geometrically contains its children is a documented source of silent boundary error — see mixed-h3-resolutions for the operational consequences when a single analysis mixes cells from more than one resolution.
Resolutions and cell size
Cell area shrinks by roughly a factor of 7 per resolution step, and edge length by roughly √7. Because H3 cells are gnomonic projections of a triangular icosahedron subdivision rather than an equal-area construction, average cell size is the only meaningful number per resolution — actual area varies by roughly 2x across the globe at a fixed resolution, largest near face centers and most distorted near face edges and vertices.
| Resolution | Avg edge length (km) | Avg cell area (km²) |
|---|---|---|
| 0 | 1107.71 | 4,250,546.8 |
| 1 | 418.68 | 607,220.9 |
| 2 | 158.24 | 86,745.9 |
| 3 | 59.81 | 12,392.3 |
| 4 | 22.61 | 1,770.3 |
| 5 | 8.54 | 252.9 |
| 6 | 3.23 | 36.1 |
| 7 | 1.22 | 5.16 |
| 8 | 0.461 | 0.737 |
| 9 | 0.174 | 0.105 |
| 10 | 0.0659 | 0.0150 |
| 11 | 0.0249 | 0.00215 |
| 12 | 0.00942 | 0.000307 |
| 13 | 0.00356 | 0.0000439 |
| 14 | 0.00135 | 0.0000063 |
| 15 | 0.00051 | 0.0000009 |
These are the published average values (h3geo.org, last verified 2026-07-22); treat them as a planning reference, not a per-cell guarantee — any individual cell at a given resolution can differ from the average by roughly a factor of 2 due to icosahedron projection distortion.
Hexagons, and the 12 pentagons
H3 cells are hexagons almost everywhere, but exactly 12 cells per resolution are pentagons — one at each of the icosahedron's 12 vertices, where the underlying polyhedron cannot be tiled with hexagons alone (Euler's formula forces at least 12 pentagonal defects on any hexagonal tiling of a sphere-like surface). Pentagon cells have 5 neighbours instead of 6, distorted area and shape relative to neighbouring hexagons, and require explicit handling in any code that assumes "a cell has 6 neighbours" as a universal invariant. See h3-pentagons for the full treatment, including which resolutions and coordinates the 12 base pentagons fall at and how they propagate to every finer resolution.
Index representation
Each H3 cell is addressed by a 64-bit integer, conventionally rendered as a 15-character hexadecimal string. The index encodes the resolution, the base cell (one of 122 base cells at resolution 0), and a sequence of per-resolution digit values describing the path down the hierarchy to the specific cell. Index bits are not simply concatenated lat/lng bits the way a Geohash string is — H3 index arithmetic is specific to H3's own subdivision scheme and does not decode meaningfully by an external system.
Core operations
- Point indexing
- `latLngToCell(lat, lng, res)` maps a coordinate to its containing cell index at a given resolution.
- Polygon fill
- `polygonToCells(loops, res)` produces the cell set covering a polygon at a resolution, under a containment mode (center, full, or overlapping) rather than a single canonical definition of 'covers.'
- Boundary extraction
- `cellToBoundary(cell)` returns the true vertex polygon for a cell (10 vertices for a pentagon, 6 for a hexagon, plus extra vertices where a cell crosses an icosahedron face edge).
- Centroid extraction
- `cellToLatLng(cell)` returns the cell's center point, used as the disk center for inscribed/circumscribed circle approximations elsewhere in this knowledge base.
- Compaction
- `compactCells(cells)` / `uncompactCells(cells, res)` losslessly re-express a same-resolution cell set as a mixed-resolution set (and back), collapsing runs of 7 sibling cells into their parent where possible — see [h3-compaction-and-uncompaction](/docs/h3-compaction-and-uncompaction/).
What must not be assumed
H3 is not equal-area: cell area varies by roughly 2x globally at a fixed resolution, so per-cell counts or densities must be area-normalized before comparison across regions. H3's logical parent/child containment is not exact geometric containment — a child cell can, in principle, extend slightly past its logical parent's true boundary, which matters for any operation assuming coarsening a cell set to a parent resolution reproduces the same covered region exactly; code needing exact geometric containment should use S2 instead, since S2's quad children exactly tile their parent. Neither property is implementation-specific; both are structural consequences of a hexagon-dominant grid on a gnomonic icosahedron projection.
References
- H3 Documentation — Uber, h3geo.org (last verified 2026-07-22)
Assumptions and limitations
The resolution/edge-length table above states average values under the
system's own published geometry; treat individual-cell deviations,
exact pentagon vertex coordinates, and library-version-specific behavior
as requiring direct verification against h3-js (or the equivalent H3
binding in use) rather than this table before a production decision.
