# openstreetmap/iD: the browser editor that keeps new mappers out of trouble > iD is the JavaScript OpenStreetMap editor that runs in the browser and deliberately limits what you can do. Here is how it works, how to build it locally, and where it stops being the right tool. **openstreetmap/iD** — 🆔 The easy-to-use OpenStreetMap editor in JavaScript. - Repository: https://github.com/openstreetmap/iD - Website: https://ideditor.com/ - Stars: 3,888 · Forks: 1,489 - Language: JavaScript - License: ISC - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/openstreetmap-id ## What iD actually solves for OpenStreetMap contributors OpenStreetMap is a shared database. Every edit lands in the same map that everyone else reads, and a wrong tag can persist for years. The README states the design goal plainly: iD "is intentionally simple. It lets you do the most basic tasks while not breaking other people's data." That sentence is the whole product thesis. iD is not trying to be the most capable OpenStreetMap editor. It is trying to be the one a first-time contributor can open in a browser without a tutorial and without corrupting a road junction. The audience follows from that. It is for people who need to fix a missing shop, add a building, correct a name, or trace a few features from aerial imagery. It is also the default editor most people meet when they click Edit on openstreetmap.org, which is why the repository lives under the openstreetmap organisation rather than a vendor account. The README lists support for Chrome, Firefox, Safari, Opera and Edge, and says data is rendered with d3.js. Desktop browsers only. There is no mobile editor claim in the README, and the RELATED SEARCHES phrase "Openstreetmap id app" is not something the documentation backs up. The constraint is the feature. A powerful editor hands you a blank tag editor and trusts you to know that a cafe is amenity=cafe and not shop=cafe. iD instead ships presets, and the repository lists id-tagging-schema as a bundled dependency. That schema is what turns a search for "coffee" into a form with the right fields. The cost is that anything outside the preset set is harder to express in iD than in a raw tag editor, which is a deliberate trade. ## How iD is put together: esbuild, d3 and the tagging schema The repository layout tells you most of the architecture. Source lives in modules/, styles in css/, icons in svg/, build output in dist/. The package.json scripts chain through npm-run-all: npm run all calls clean, build and dist in sequence, and build itself splits into build:css, build:data and build:js. Each of those is a Node script under scripts/ or a config file under config/. The bundler is esbuild, invoked from config/esbuild.config.js for development and config/esbuild.config.min.js for the minified distribution build. Data is a separate build step. build:data runs scripts/build_data.js and writes into dist/data, which is where the tagging presets, the name-suggestion-index and the community index end up. Those three pieces come from outside the repository: id-tagging-schema, name-suggestion-index and osm-community-index are all listed in the README as bundled open source software. So the editor you build is assembled from a rendering layer, a preset layer and an index of community resources, not from one monolithic codebase. Rendering is d3.js, listed under BSD-3-Clause. That matters if you are auditing licences, because d3 is not the only third-party component. The README also lists CLDR under Unicode Consortium Terms of Use, editor-layer-index under CC-BY-SA 3.0, Font Awesome under CC-BY 4.0, Maki and Temaki under CC0 1.0, the Röntgen icon set under CC-BY 4.0, Mapillary JS under MIT, and the three indexes named above. The dist:mapillary and dist:pannellum scripts copy those libraries' own dist folders into the output, so the built site carries code under at least seven different licences. iD's own code is ISC, which is permissive and short, but ISC on the repository does not relicense the bundled parts. The repository also carries ARCHITECTURE.md and API.md at the top level. If you intend to embed or extend iD rather than just run it, those two files are the ones to read before the source, and the README does not summarise their contents. ## Installing iD locally and making your first edit The README is explicit that installation is not covered there. It says to follow the steps in the how to get started guide on the project wiki, under build and test instructions. There are no install commands in the README itself, so treat the wiki page as the authority and the commands below as the shape of the workflow implied by package.json. You need Node.js. The repository carries an .nvmrc file at the top level, which is the project's own statement of which Node version it expects, so read that file and match it rather than guessing. Once your Node version matches, install dependencies from the repository root: ```bash npm install ``` With dependencies in place, the package.json scripts give you the build. A one-shot production-style build runs clean, then the three build steps, then the dist tasks: ```bash npm run all ``` For development, the watch script rebuilds JavaScript as you edit. The README points contributors at the develop branch, and the netlify mirrors it lists are the quickest way to see a running editor without building anything: https://ideditor-release.netlify.app mirrors the release branch, and https://ideditor.netlify.app mirrors develop with the latest translations. To make an edit, open the built editor in a desktop browser, pan to an area, and use the preset search rather than typing tags by hand. Searching a term pulls the matching preset from the tagging schema, and the form it renders constrains the keys you can set. Save, and the change goes to the OpenStreetMap API. The FAQ.md and PRIVACY.md files at the repository root cover questions about accounts and data handling that the README does not. ## Where iD is the wrong editor The README's own framing is the limitation. "Intentionally simple" means iD does not aim at bulk operations, complex relations, or mechanical edits across thousands of objects. If your task is re-tagging every bus stop in a city, iD will make you do it one at a time, and the preset forms will fight you on any tag the schema does not model. There is a second, sharper failure mode. Because the preset system is the interface, an object whose tags fall outside the schema presents you with a form that does not describe it. You can still edit raw tags, but the guidance that makes iD safe for newcomers stops helping, and the risk of the exact data damage the README warns about goes up. This is the opposite of a bug: it is the boundary of the design. The build side has its own limits. The README states the project expects regular update releases about every month, and the release history shows v2.42.0, v2.42.1 and v2.42.2 landing within ten days of each other in August 2026. If you fork iD and patch it, you are maintaining a fast-moving fork against a develop branch that is already at 2.43.0-dev. The repository has no documented rollback procedure in the README, so a bad release is handled by the project's own release process, described in RELEASING.md, not by anything you can trigger from the editor. Finally, browser support is desktop only. Chrome, Firefox, Safari, Opera and Edge are the listed targets. If your contributors work from phones or tablets, the README gives you nothing to rely on. ## iD against JOSM: presets versus raw tags The obvious alternative is JOSM, the long-standing desktop OpenStreetMap editor written in Java, and the RELATED SEARCHES phrase "OpenStreetMap Java" points at that same neighbourhood. The difference is not polish, it is where the complexity sits. JOSM is a desktop application you install and configure, with a plugin ecosystem and a raw tag interface as the primary way of working. iD is a page you load in a browser, with a curated preset schema as the primary way of working. JOSM assumes you know what you are tagging and gives you the full vocabulary. iD assumes you might not, and gives you a narrower vocabulary that is hard to get wrong. That makes them suit different jobs rather than compete on the same axis. A mapping party with first-time volunteers wants iD, because the preset forms are the instruction manual. An import of a municipal dataset, or a mechanical fix across a region, wants a desktop editor with scripting and bulk selection. Choosing iD for the second job means working against its stated design, and choosing JOSM for the first means handing beginners a tool that will let them tag a school as a restaurant without complaint. The two also differ in distribution. iD ships as a bundled web build with its data compiled in at build time, which is why the tagging schema, the name index and the community index are dependencies rather than downloads. A desktop editor's presets can be updated independently of the application. That is a real architectural difference, not a preference. ## Licence position and what a fork inherits iD's own code is ISC, a permissive licence that permits reuse and redistribution with the copyright notice retained. The LICENSE.md file at the repository root carries the full text. That part is straightforward. The bundled components are not. The README lists D3.js under BSD-3-Clause, CLDR under Unicode Consortium Terms of Use, editor-layer-index under CC-BY-SA 3.0, Font Awesome under CC-BY 4.0, Maki and Temaki under CC0 1.0, Röntgen under CC-BY 4.0, Mapillary JS under MIT, and id-tagging-schema, name-suggestion-index and osm-community-index under ISC, BSD-3-Clause and ISC respectively. CC-BY-SA 3.0 is the one to look at closely, because share-alike terms attach to derivative works in a way that ISC does not. The dist:mapillary and dist:pannellum scripts copy whole third-party dist directories into the build output, so a redistributed build carries those files verbatim. This is a description of what the repository states, not legal advice. If you plan to ship a modified iD under your own banner, the licence inventory is the first thing to hand to whoever handles that, and the README's list is the starting point rather than a complete audit. ## Conclusion Adopt iD if you want a browser-based OpenStreetMap editor whose preset system prevents new contributors from inventing tag combinations, and if your workflow fits the basic editing tasks the README describes. Do not adopt it if you need bulk edits, custom data pipelines, or a headless editor for automation: the README frames iD as intentionally simple, and the repository points elsewhere for heavy work. Before you build, read the how to get started guide linked from the README, since that wiki page, not the README itself, carries the build and test instructions. Then check whether the develop branch mirror at https://ideditor.netlify.app reflects the version you intend to ship, because the README distinguishes it from the release mirror. ## FAQ ### How do I install openstreetmap/iD locally? The README does not contain install steps. It directs you to the how to get started guide on the project wiki for build and test instructions, and the package.json scripts (clean, build, dist) describe the build pipeline those instructions drive. ### Which browsers does the openstreetmap/iD editor support? The README lists Chrome, Firefox, Safari, Opera and Edge, and describes them as popular modern desktop browsers. No mobile browser support is claimed. ### What licence is openstreetmap/iD released under? iD itself is available under the ISC License, with the full text in LICENSE.md. The README also lists bundled third-party components under other licences, including BSD-3-Clause, CC-BY-SA 3.0, CC-BY 4.0, CC0 1.0 and MIT. ### Where can I try openstreetmap/iD without building it? The README gives two mirrors: https://ideditor-release.netlify.app for a stable mirror of the release branch, and https://ideditor.netlify.app for the develop branch with the latest translations. ### What is the openstreetmap id tagging schema? It is the preset data iD uses to turn a search term into a form with the right OpenStreetMap tags. The README lists id-tagging-schema as a bundled dependency under the ISC licence, and the build:data script writes it into dist/data. ## Sources - [License: ISC](https://github.com/openstreetmap/iD/blob/develop/LICENSE) - [openstreetmap/iD on GitHub](https://github.com/openstreetmap/iD) - [Project website](https://ideditor.com/) - [README](https://github.com/openstreetmap/iD/blob/develop/README.md) - [Releases](https://github.com/openstreetmap/iD/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openstreetmap-id