GeoJSON Stats

What this tool does

A single pass produces the numbers that decide what to do next: how many features there are, how they break down by geometry type, how many coordinate positions the file holds in total, how many polygon rings, the combined bounding box, and which single geometry is the heaviest.

It also profiles the attribute table. Every property key is listed with the number of features that have it, that as a percentage, and the JSON types seen — which is how you spot the key that is a string in some features and a number in others, or the one that only 4% of features actually carry.

How this tool works

Count, profile, report.

1. Count the geometry

Features are normalised (collection, single feature, or bare geometry) and walked. Each feature's geometry type is tallied, its positions counted recursively so nested MultiPolygon coordinates are included, and polygon rings counted separately. Features with a null geometry are counted on their own line rather than silently ignored.

2. Profile the properties

For every feature, each property key is recorded along with the JSON type of its value — string, number, boolean, object, array, or null. Keys are then sorted by how often they appear, so the core attributes come first and the sparse ones fall to the bottom.

3. Report

The text report is aligned for reading and pasting into an issue. The JSON format holds the same figures as a structured object — feature and vertex counts, the geometry-type histogram, the bbox, and a property array with fill percentages — for use in a script or a note.

Options

Format

Text report to read now; JSON when the numbers are going into something else. Both come from the same single pass, so they always agree.

Example

Input: a small mixed collection

{"type":"FeatureCollection","features":[
  {"type":"Feature","properties":{"name":"A","pop":10},"geometry":{"type":"Point","coordinates":[0,0]}},
  {"type":"Feature","properties":{"name":"B"},"geometry":{"type":"Polygon","coordinates":[[[0,0],[1,0],[1,1],[0,0]]]}}
]}

Output (trimmed):

Features           2
Vertices           5
Polygon rings      1
bbox               [0, 0, 1, 1]
Property keys      2

Geometry types
  Point             1
  Polygon           1

Properties (key · present · fill · types)
  name              2  100%  string
  pop               1  50%   number

The pop line is the interesting one: half the features have it. That is exactly the kind of gap that makes a choropleth render blank patches, and it is invisible when you eyeball the first few features.

Tips & common pitfalls

• Vertices predict performance. Web maps start to feel slow in the low hundreds of thousands of positions. If the count is high, simplify and round before styling.
• A mixed type column is a bug waiting. A key listed as string/number means some features quote the value and some do not — sorting and filtering will behave inconsistently downstream.
• Low fill rates explain missing symbols. A property present on 20% of features means 80% will fall through to your default style.
• The heaviest geometry is often the problem. One feature with 200,000 vertices in a file of 500 features is a classic cause of a hanging map.

FAQ

What counts as a vertex?

Every coordinate position in the document, at any nesting depth. A polygon ring's repeated closing position is counted, since it is genuinely there in the file.

Does it validate the file?

No — it measures. Use the validator for RFC 7946 conformance, which is a different question from "how big is it".

Why is my property fill rate below 100%?

Because some features do not have that key at all. GeoJSON does not require a uniform schema, so ragged attribute tables are common in merged or converted data.

Is anything uploaded?

No. The whole measurement runs in the page.