How Large Is Too Large for GeoJSON?

There is no universal file size at which GeoJSON suddenly becomes “too large”.

A 20 MB GeoJSON file can be perfectly workable in one application and frustratingly slow in another. Performance depends on what the data contains, how it is transferred, what the client must do with it, and how much of it needs to be visible or interactive at once.

Feature count matters, but so do geometry complexity, coordinate precision, attribute size, browser memory, styling, labels, spatial processing, and whether the application loads the entire dataset or only the portion the user currently needs.

So the better question is not:

“How many megabytes can GeoJSON handle?”

It is:

“At what point does sending this dataset as one GeoJSON document stop being a sensible delivery model for this application?”

There is no standard GeoJSON size limit

RFC 7946 defines the structure and geographic conventions of GeoJSON, but it does not establish a maximum file size, maximum feature count, or browser-safe threshold.

A FeatureCollection containing ten features and another containing one million features are still described by the same data model.

The difference is operational.

A large GeoJSON dataset may have to be:

1. transferred over the network;

2. decompressed if HTTP compression is used;

3. held as text or bytes;

4. parsed as JSON;

5. represented as JavaScript or native objects;

6. processed into the mapping library's internal structures;

7. indexed, tiled, simplified, or otherwise prepared;

8. styled and rendered;

9. queried when the user interacts with it.

The .geojson file size visible on disk describes only part of that workload.

This is why two files of similar size can behave very differently in the same application.

Feature count is only one measure of complexity

Consider two datasets.

Dataset A

200,000 points

Each feature contains a coordinate and one short numeric property.

Dataset B

500 polygons

Each polygon traces an extremely detailed boundary with tens of thousands of vertices and carries dozens of large text attributes.

Dataset B can easily be more expensive to transfer, parse, process and render despite containing far fewer features.

A feature is therefore not a fixed unit of geographic complexity.

Points can be represented with a single position:

{
  "type": "Point",
  "coordinates": [11.52, 3.87]
}

A polygon can contain thousands or millions of coordinate values.

This is why geometry complexity and file size deserve to be considered separately from raw feature count.

File size still matters

Even though megabytes are not the whole story, they are not irrelevant.

GeoJSON is a text format. Coordinates, property names, strings, brackets, commas, and structural keywords are all represented in the document.

For example:

{
  "type": "Feature",
  "properties": {
    "population_estimate": 125340,
    "administrative_name": "Example District"
  },
  "geometry": {
    "type": "Point",
    "coordinates": [11.523456, 3.876543]
  }
}

Repeat those structures thousands of times and the text grows.

Larger files generally mean more data to transfer and more content for a client to parse. Compression such as gzip or Brotli can reduce the network transfer considerably because GeoJSON contains a lot of repeated text, but the receiving application still needs to reconstruct and process the actual JSON data afterwards.

So a compressed 8 MB download is not equivalent to an 8 MB in-memory geographic dataset.

The transfer may be manageable while parsing or rendering remains expensive.

Coordinate precision can make a surprising difference

GeoJSON size is affected not only by how many coordinates exist, but by how many digits each one contains.

RFC 7946 explicitly identifies coordinate precision as an interoperability consideration. It notes that for a GeoJSON document containing many detailed polygons, increasing coordinate precision from six to fifteen decimal places can inflate the text by almost a factor of two. It therefore recommends considering the cost of carrying more precision than the application actually needs. (rfc-editor.org)

Consider:

11.523456

versus:

11.523456123456789

For one point, the difference is trivial.

Across several million vertices, it is not.

And additional decimal places do not necessarily represent additional geographic accuracy. As discussed in The False Precision of Exact Coordinates, numerical precision can exceed what the source evidence actually supports.

Reducing unjustified coordinate precision can therefore improve both the intellectual honesty and the technical efficiency of a dataset.

That does not mean arbitrarily rounding every GeoJSON file. The required precision depends on the geography and purpose of the data.

Properties can make a small geometry dataset large

A map may use only two properties while each feature carries fifty.

Suppose a point layer contains:

{
  "name": "Facility A",
  "category": "Health"
}

and the application only needs those two values.

If the GeoJSON also transports:

• long descriptions;

• unused database identifiers;

• audit fields;

• source-system metadata;

• URLs;

• duplicate names;

• several historical values;

• large nested objects;

then much of the payload may be irrelevant to the map.

MapLibre's current guidance for large GeoJSON sources specifically recommends removing unused properties as one of the first ways to reduce loading cost. It also recommends reducing unnecessary coordinate precision and simplifying geometry where appropriate.

The important qualifier is unused.

Deleting attributes solely to make a file smaller can destroy useful data. The correct optimisation is to deliver only the information required for that particular application while preserving the authoritative richer dataset elsewhere when needed.

Rendering can become the bottleneck even after loading succeeds

A GeoJSON file is not necessarily usable simply because the browser successfully downloads and parses it.

The map must still display it.

Rendering 100,000 plain points is different from rendering 100,000 labelled points with several style expressions, collision detection, interactive states, and complex symbols.

Dense geometry creates similar issues.

At a world view, displaying every vertex of a detailed municipal boundary may contribute no useful visible information because many vertices fall within the same screen pixels. Likewise, drawing every individual point in a dense dataset at zoom level 2 can produce both poor performance and an unreadable map.

MapLibre's performance guidance therefore treats loading and visualisation as separate problems. Its recommendations include point clustering, simplified styling, appropriate minimum and maximum zoom levels, data reduction, chunking, streaming, and vector tiling.

That distinction is important.

A dataset may be technically loadable but still be too large for the interaction you expect from it.

So is 10 MB too large?

Not necessarily.

Neither is 50 MB automatically acceptable.

A small GeoJSON file can perform poorly if it contains extremely complex geometry or drives expensive visual behaviour. A much larger file may be workable in a desktop environment when it is loaded once for a relatively simple operation.

The device matters too.

A dataset that behaves acceptably on a developer's workstation can perform badly on:

• an older laptop;

• a budget smartphone;

• a device with limited memory;

• a slow mobile connection;

• a browser already running a memory-intensive application.

This is why publishing a single file-size threshold as a general GeoJSON rule is misleading.

The threshold belongs to the workflow and performance budget, not to the format specification.

What about feature-count thresholds?

These should also be treated carefully.

Mapbox's current guidance for its GL JS implementation describes sources above roughly 500,000 data points as entering a range where additional strategies such as splitting the source or server-side tiling should be considered.

That is useful practical evidence, but it should not be converted into:

GeoJSON supports 500,000 features.

The guidance is specific to a particular mapping architecture and even uses the broader term data points, not a universal GeoJSON feature limit.

Five hundred thousand simple points and five hundred thousand complex polygons are radically different workloads.

The sensible lesson is that once a dataset reaches hundreds of thousands of geographic elements, it is worth questioning whether one monolithic client-side GeoJSON document remains the appropriate delivery model.

The exact transition point must still be measured in the application that will use it.

First ask whether the entire dataset needs to reach the browser

This is often the most important optimisation.

Suppose a database contains every road in a country, but a user is looking at one city.

Does the browser actually need the whole country?

If not, reducing coordinate precision or shaving a few property names from a giant national GeoJSON file addresses only part of the problem.

A better architecture may return only the features required for the current:

• map extent;

• zoom level;

• query;

• time range;

• category;

• user task.

MapLibre's guidance suggests both data streaming and server-side tiling when whole-document loading stops being appropriate.

This changes the performance problem fundamentally.

Instead of repeatedly trying to make the entire dataset small enough for the browser, the application stops sending most of the dataset when most of it is not needed.

Simplify geometry when the extra detail cannot be seen

Detailed geometry is another common source of unnecessary GeoJSON size.

Imagine a coastline containing a vertex every few metres.

That detail might matter in a large-scale local analysis. At a continental map view, it cannot all be perceived.

Geometry simplification can reduce the number of vertices while maintaining an appropriate approximation of the original shape for the intended scale.

MapLibre explicitly recommends simplifying large GeoJSON data and also allows GeoJSON-source tolerance to influence geometry simplification during its internal processing.

But simplification is not harmless.

It can:

• move boundaries;

• remove small features;

• alter topology;

• change calculated areas or lengths;

• erase narrow geographic structures.

The correct approach is therefore not “simplify until the file loads quickly”.

It is to create a representation whose geometric detail is appropriate for its display purpose, while retaining the more detailed source data when that detail is analytically important.

This is one reason web-map delivery datasets and authoritative analytical datasets do not always need to be identical.

Clustering helps dense point maps for two reasons

Point clustering is commonly described as a performance optimisation, but it is also a cartographic one.

At a low zoom level, a map might not have enough screen space to distinguish 100,000 individual points. Drawing them all creates visual noise while making the renderer do more work.

A cluster can instead communicate:

many features occur around here

and expose the individual points as the reader zooms closer.

MapLibre recommends clustering as a way to reduce the number of point features that must be visualised at once, improving rendering performance while also making dense datasets easier to understand.

The important question is whether aggregation preserves the meaning required by the map.

If every individual feature must remain immediately inspectable at every scale, clustering changes the interaction model. If the overview is intended to show concentration before details, it may improve both performance and communication.

Splitting a GeoJSON can help, but it does not solve every problem

Another option is to divide one dataset into several GeoJSON sources.

This can be useful when the parts have meaningful differences.

For example:

current_view.geojson
rest_of_region.geojson

or:

dynamic_features.geojson
static_features.geojson

The application may then load or update the parts differently.

MapLibre recommends chunking as one strategy for large datasets, particularly when different parts of the data have different loading or update requirements. It notes that the benefits can vary across desktop and mobile environments.

But splitting:

100 MB

into:

4 × 25 MB

does not automatically make the underlying workload disappear if all four files are immediately loaded, parsed and rendered anyway.

Chunking helps when it enables a different loading strategy.

Otherwise, it can simply turn one large problem into several smaller files representing the same total problem.

When should you move to vector tiles?

When the map does not need the entire raw dataset at once, vector tiles are often the more scalable representation.

Instead of delivering one FeatureCollection containing every feature, tiled delivery partitions geographic content spatially and by zoom level. A map requests the portions relevant to the current view.

This can provide several advantages:

• the initial transfer can be much smaller;

• the client need not hold the entire dataset at once;

• different levels of geometric detail can be provided at different zooms;

• server-side processing can prepare data before delivery;

• the map can request new areas as the user moves.

MapLibre explicitly recommends vector tiling for large GeoJSON datasets and points to server-side tiling for still larger sources.

This does not make vector tiles a universal replacement for GeoJSON.

GeoJSON remains easier when an application needs the complete editable features, arbitrary properties, straightforward API responses, or direct access to the original vector objects.

The trade-off deserves its own treatment in GeoJSON vs Vector Tiles.

A useful test: what happens as the dataset grows?

Rather than asking for a universal number, test the workflow against the things users actually experience.

Watch:

Transfer time How long before the geographic payload reaches the client?

Parse and preparation time How long before the application can actually use it?

Memory Does loading the layer produce unacceptable memory pressure?

Time to first useful map Can the reader start interacting before all geographic content is processed?

Pan and zoom responsiveness Does navigation remain smooth?

Style and label performance Do expensive symbols or collision calculations become the limiting factor?

Interaction latency Do clicks, hovers, filters, or queries remain responsive?

Mobile behaviour Does the same workflow remain usable on less powerful devices?

A GeoJSON source has become “too large” when it prevents the application from meeting the performance and interaction requirements that matter to its users.

That can happen before the browser crashes.

Optimise in the right order

When GeoJSON begins to become uncomfortable, a useful progression is:

1. Remove data the application does not need. Unused attributes and irrelevant features are the cheapest bytes to process because they should never have been transferred.

2. Avoid unjustified coordinate precision. Keep enough precision for the purpose, not simply every digit available upstream. RFC 7946 explicitly highlights this cost. (rfc-editor.org)

3. Simplify geometry where the display scale permits it. Do not transport detail that cannot be perceived.

4. Adjust the visualisation. Cluster points, constrain visibility by zoom, and avoid unnecessarily expensive styling.

5. Load only what is needed. Chunk, filter, stream, or query data rather than treating every map as a full-dataset download.

6. Change the delivery model. When the application fundamentally works by geographic extent and zoom level, vector tiles or another spatially partitioned representation may be more appropriate.

This order matters because optimisation should first remove unnecessary work before introducing additional infrastructure.

GeoJSON is often excellent precisely because it is simple

It would be a mistake to conclude that GeoJSON is only appropriate for tiny datasets.

For many APIs, analytical results, application states, editing workflows, small-to-medium map layers, and data interchange tasks, its simplicity is a major advantage.

A developer can inspect it directly. Standard JSON libraries understand its syntax. Geographic features and their properties remain explicit. It works naturally across the boundary between GIS and ordinary application development.

The problem begins when that simplicity is asked to perform a job better suited to a spatial delivery system.

If a browser must receive a country's entire road network just to show the roads around one neighbourhood, the fundamental issue may no longer be how many decimal places GeoJSON contains.

It may be that the browser should never have received the entire network in the first place.

So there is no universal answer to “How large is too large for GeoJSON?”

The useful answer is:

GeoJSON is too large when delivering and processing the whole document becomes more expensive than the simplicity of using the format is worth.

At that point, simplify what can safely be simplified, stop sending what the user does not need, and—when necessary—change the way the geography is delivered rather than continuing to optimise one increasingly enormous JSON document.

References

1. IETF RFC 7946 — The GeoJSON Format. Defines GeoJSON and discusses coordinate precision and document-size considerations without imposing a universal file-size limit.

2. MapLibre GL JS — Optimising MapLibre Performance: Tips for Large GeoJSON Datasets. Covers property reduction, coordinate precision, geometry simplification, chunking, streaming, clustering, vector tiling, and zoom-level optimisation.

3. Mapbox — Working with Large GeoJSON Sources in Mapbox GL JS. Provides implementation-specific guidance for loading and rendering large GeoJSON sources, including clustering, source splitting, simplification, and server-side tiling.

4. GDAL — GeoJSON Driver. Documents GeoJSON parsing, coordinate precision options, feature handling, and implementation-specific size behaviour in GDAL.