DEV Community: Andrew Sepic

Rebuilding geojson.io: A Look at the 2026 Overhaul

Andrew Sepic — Mon, 10 Aug 2026 15:37:35 +0000

If you've worked with spatial data on the web, you've probably used geojson.io. Since Tom MacWright first built it in 2013, it's become one of those quietly indispensable tools in the mapping community — drop in a GeoJSON file, sketch a polygon, grab a quick bounding box, copy the coordinates back out. No GIS software, no setup, just a browser tab.

geojson.io screenshot from October 2, 2015 - courtesy of Wayback Machine

This year we shipped the biggest change in the app's 13 year history: a full overhaul of the editor, cut over to production on June 1, 2026. Below is how we approached this, what changed, why, and what's shipped since.

Why overhaul it

geojson.io's core had aged in place for a while. Under the hood, it had already been through one generation of map tech — originally built on Leaflet-based Mapbox.js library, then refactored to Mapbox GL JS and Mapbox GL Draw in 2022 — but the application itself never changed alongside it. The UI was built entirely with D3, using its selection and data-join API as a general application-construction tool rather than for what it's best known for: data visualization. D3 has no built-in component model or state management, so anything beyond simple DOM bindings meant hand-rolling patterns a modern framework gives you for free.

Rather than start from the ground up, we forked Placemark Play — an open-source geojson editor, also built by Tom MacWright, with an editing model designed from the start around multiselect and structured data editing — and adapted it into geojson.io's new foundation.

How we approached it

Rewriting a decade-old tool creates an obvious risk: breaking workflows people depend on in the name of modernization. So one guiding principle shaped the whole project — treat every piece of legacy functionality as a question, not a given. Is this still useful? If so, does it need to look the same, or can it be replicated in a different pattern that fits better with the new architecture? Some features carried over largely unchanged; others got rebuilt around Placemark's multiselect-first editing model because the old pattern didn't make sense once "selection" could mean more than one feature at a time. That same audit ran in both directions — Placemark Play came with plenty of its own functionality that didn't serve geojson.io's specific mission, so a fair amount of the fork was just as much about stripping code out as building on top of it.

We also didn't cut over all at once. The update launched quietly at a parallel /next path back in January 2026, running alongside the legacy app so real usage and feedback could shape it before it became the default. That turned into a long stretch of triaging GitHub issues and user reports — and a lot of it wasn't about missing features so much as discovering how people were actually using geojson.io, often in ways we hadn't designed for or could have imagined. Users had built workflows around edge cases and quirks of the old app, well outside anything we'd call the "intended" use case. Each one became a judgment call: is this worth supporting, or would chasing it add complexity and noise the core tool doesn't need? We're still working through some of those today.

It's ended up being as much a product exercise as an engineering one — shaped by feedback from Mapbox teams using it internally, and by the broader open-source GIS/mapping community, who've been generous (and opinionated, in the best way) about what they need from a tool like this.

What Placemark gave us

Forking Placemark Play didn't just hand us a newer codebase — it came with capabilities legacy geojson.io never had, the kind of thing that would've been its own multi-month project to build from scratch. Multiselect and bulk editing meant selecting many features at once and updating their properties together, instead of one at a time. Real editing history — undo/redo, copy, duplicate — plus spatial and geometry operations. Improved data management, with a list view and table view alongside the map, name previews for features, and a feature editor that treats properties as structured data instead of a JSON blob you hand-edit. And a codebase built for the present — modern React patterns and TypeScript that are both easier for us to maintain and a lower bar for outside contributors.

The new stack

The overhaul moved the app to React 18, Vite, and TypeScript. A few of the more interesting pieces under the hood:

A More Capable Editing Toolkit All drawing and editing logic is custom, built around a PMap class that wraps Mapbox GL JS (v3.24.0) directly and layers a Deck.gl MapboxOverlay ( (@deck.gl/core, @deck.gl/mapbox, v9) on top for vertex rendering, selection highlighting, and snapping— This keeps a clean separation of concerns: Mapbox GL JS is responsible for rendering the app's GeoJSON data, while Deck.gl owns the editing UI — vertex handles, selection highlighting, and snapping.
State lives in Jotai atoms, with atomWithStorage things like camera position and UI preferences go straight to localStorage/sessionStorage, no separate persistence layer needed.
Heavy lifting happens off the main thread. Format conversion and reprojection — parsing a Shapefile, converting a big XLSX, reprojecting coordinates — runs in a Web Worker, built natively by Vite's worker support, so importing a large file doesn't freeze the map or the UI.
TypeScript earns its keep on the data model. GeoJSON Features, Geometries, and FeatureCollections aren't just untyped JSON — they're well-defined union types, and typing them properly catches a real class of bugs (wrong geometry type, malformed coordinate arrays) at the boundary, before they ever hit the map.

What we built on top

Placemark's foundation covered the editing and data model — what it didn't cover was the specific functionality legacy geojson.io users had come to expect: globe projection, custom raster layers, sharing, and a long tail of smaller behaviors. Closing those gaps, alongside genuinely new capability, has been most of the work since launch:

The geojson text editing panel (using CodeMirror), was a core part of the legacy geojson.io and ensures that your geojson text is still front and center next to your map. This helps beginners understand the geojson specification and formatting and also allows for direct editing and syncing to app state.
Moving the Feature Editor into it's own flexible dynamic pop up, giving full control over a wide array of data on the selected feature.
Simple Style Spec support for Markers & Polygons — render and edit simple style spec marker-color, marker-symbol, fill-color and more.
Custom raster layers, including WMS support and TMS tilesets with inverted Y coordinates, so you can bring your own basemap imagery.
Globe projection and 3D, with a toggle between globe and mercator, plus pitch/rotation for tilted views — integrating globe projection with Deck.gl's still-experimental support was one of the trickier parity problems.
Vertex snapping while dragging, so edited or drawn geometries snap cleanly to nearby features and vertices.
Shareable URLs — features are zipped and base64-encoded into a link, so you can hand someone a working map of your data without a backend.
A steady stream of smaller fixes: streamlined file import for unambiguous formats (GeoJSON, KML, GPX, Shapefile skip the dialog entirely now), mobile panel resizing and two-finger pan while drawing, and persisted camera state that survives a page reload.

It's a lot of surface area for a tool that's supposed to stay simple, and keeping it feeling simple — while adding real capability underneath — has been the actual design challenge of this overhaul.

The new geojson.io

Still open source

geojson.io remains open source, and the overhaul hasn't changed that. If you hit a bug or have a feature request, open an issue on
GitHub — and if you want to see where it's headed, the full changelog is public too.

Thanks to Tom MacWright for building geojson.io in the first place, and for Placemark Play, which gave this project most of its DNA.

Unlocking Mapbox GL JS's Hidden Field of View Control

Andrew Sepic — Tue, 10 Feb 2026 14:49:30 +0000

Ever wished you could make your Mapbox map look more like a telephoto lens or a dramatic wide-angle shot? Turns out, there's an undocumented way to control the camera's field of view (FOV) in Mapbox GL JS—but with a big caveat: this is not a public API.

⚠️ Developer Warning: What I'm about to show you involves accessing private internal properties. Use this only for experiments, prototypes, and creative projects. Don't rely on this in production—it could break in any future Mapbox version without notice.

The Problem: Fixed Field of View

By default, Mapbox GL JS uses a fixed vertical field of view of approximately 36.87 degrees (0.643 radians). This gives maps a consistent, neutral perspective. But what if you want to:

Create a telephoto effect (narrow FOV) for architectural visualization
Achieve a dramatic wide-angle view (large FOV) for immersive experiences
Dynamically adjust the visual perspective based on user interaction

The official Mapbox API doesn't expose FOV control—but the internal Transform class does.

What is the Transform Class?

Digging through the Mapbox GL JS source code, I discovered the Transform class—the mathematical heart of Mapbox's rendering system. This 2,800+ line beast handles:

Camera positioning and orientation
Projection matrix calculations
Coordinate system transformations (lat/lng ↔ screen pixels ↔ mercator)
Zoom level calculations
Field of view management

The Transform instance lives at map.transform and contains a private _fov property that controls the vertical field of view.

The (Unofficial) Solution

Here's how you can control field of view with a custom function called setFOV.

function setFOV(map, fov) {
  // Directly access the internal Transform instance
  map.transform._fov = fov;

  // Force recalculation of projection matrices
  map.transform._calcMatrices();

  // Trigger a map repaint
  map.triggerRepaint();
}

// Initialize your map
const map = new mapboxgl.Map({
  container: 'map-container',
  center: [-71.06288, 42.36834],
  zoom: 16.85,
  pitch: 75.67,
  bearing: 141.60
});

map.on('load', () => {
  // Apply a custom FOV (in radians)
  setFOV(map, 0.8); // Wide angle
  // setFOV(map, 0.4); // Telephoto
});

FOV Values Explained

Radians	FOV effect
0.1 - 0.5 radians (~5-28°): Telephoto effect, compressed perspective
0.643 radians (~36.87°): Default Mapbox FOV
0.8 - 1.5 radians (~45-86°): Wide angle, dramatic perspective

How It Works Under the Hood

When you modify _fov, three things need to happen:

Update the property: map.transform._fov = newValue
Recalculate matrices: map.transform._calcMatrices() recomputes all the projection math including:
- projMatrix - world to clip coordinates
- pixelMatrix - world to screen pixels
- cameraToCenterDistance - camera distance based on FOV
Trigger repaint: map.triggerRepaint() forces a redraw with new matrices

The _calcMatrices() method is where the magic happens. From the source:

this.cameraToCenterDistance = 0.5 / Math.tan(this._fov * 0.5) * 
  this.height * this._pixelsPerMercatorPixel;

This calculates how far the camera should be from the map center based on the FOV, ensuring the perspective projection renders correctly.

Interactive Field of View Controller

Want to let users adjust FOV dynamically? Here's a complete example with a slider you can check on on Codepen.

Why Isn't This a Public API?

You might wonder why Mapbox doesn't officially expose FOV control. A few reasons:

Complexity: Changing FOV affects tile loading, symbol placement, and many other rendering systems
Performance: Non-standard FOV values can impact rendering performance
Consistency: A fixed FOV ensures consistent user experience across applications
Maintenance: Supporting arbitrary FOV would increase API surface area and testing burden

The Risks

Before you rush to implement this, understand the risks:

⚠️ Breaking changes: Internal APIs can change without warning in minor/patch releases
⚠️ Unsupported behavior: You may encounter rendering artifacts or unexpected behavior
⚠️ No guarantees: Mapbox won't provide support for issues arising from this technique
⚠️ Version locked: You'll need to test across Mapbox versions if you update

Alternative: The FreeCamera API

For production use cases involving advanced camera control, check out Mapbox's official FreeCamera API. While it doesn't expose FOV directly, it provides:

Full camera position control
Orientation adjustments
Supported and stable API
Works with all Mapbox features

Conclusion

Exploring internal APIs like Transform is a fantastic way to understand how sophisticated mapping libraries work under the hood. The FOV control technique shown here opens creative possibilities for enthusiasts and experimental projects.

Just remember: with great power comes great responsibility. Use internal APIs wisely, always have a fallback, and consider this a learning exercise rather than a production strategy.

Tested with Mapbox GL JS v3.18.1. Your mileage may vary with other versions.

Additional Resources

Build quickly with npm create @mapbox/web-app

Andrew Sepic — Fri, 12 Dec 2025 15:45:44 +0000

The Mapbox Developer Relations team recently released a new developer tool to help web developers quickly scaffold Mapbox GL JS into their favorite frontend frameworks. You can now go from zero to hero with a map in your app in about 10 seconds. 🚀

To get started, ensure you have npm installed and run the command in your terminal.

$ npm create @mapbox/web-app

(Requires Node.js v20+.)

Why this is helpful

If you work with Mapbox GL JS in modern JavaScript frameworks, you'll know that spinning up a map in your app can take more time and effort than you'd like. This tool abstracts away project configuration, dependency management and lets developers get a simple map running very quickly. This allows you to test ideas & features fast, without having to clone a local repo or project as a starting point.

`npm create @mapbox/web-app`

The npm create @mapbox/web-app package is a CLI tool that uses Vite templates to quickly build a project into the following frameworks:

Vanilla JS (with & without a bundler)
React
Vue
Svelte
Angular

You can also also add interactive search to your map by adding Mapbox Search JS via the install prompts.

The CLI tooling asks 4 questions:

Which framework do you want to use?
Choose a project name..
Access Token - Insert your public Mapbox access token and the tooling will pass this into the appropriate local .env file. Get yours from your developer console
Add Search JS (or not)

After answering those questions you'll have a full-screen Mapbox GL JS map loading in the browser within seconds, ready for you to customize. 🔥

Next Steps

Now that you have a full screen map loaded, where do you want to go next? If you are a new developer using Mapbox, you can expand this simple application by following one of these tutorials:

The tutorials above demonstrate state management best practices for these frameworks, how to track & display map state into the application UI and how to trigger map events from the UI.

If you are an experienced developer and are familiar with Mapbox products, you can browse our tutorials for inspiration or search them for your use case.

More Information on Github

You can find more information about this CLI tool and report issues on Github.