Blockbench: a low-poly 3D model editor you can run in a browser or as a desktop app

What Blockbench solves, and who it is actually for

General 3D packages assume you want subdivision surfaces, sculpting brushes and a physically based render pipeline. Blockbench assumes the opposite. The README describes it as "a free and open source model editor for low-poly models with pixel art textures", and that constraint is the product. A Minecraft mob or a pixel-art item model is a small mesh with a texture atlas, and the work is mostly moving cubes and UV islands, not simulating light.

The audience follows from that. If you make Minecraft Java or Bedrock content, the README states there are "multiple dedicated formats for Minecraft Java and Bedrock Edition with format-specific features", which means the export step understands the target rather than treating it as a generic OBJ. If you are a beginner, the README calls the interface "modern and beginner friendly". If you are experienced, the same paragraph points at "lots of customization and advanced features". Those two claims pull in opposite directions and the project tries to satisfy both, which is a real design tension rather than a marketing line.

It is not a Blender replacement and the README never claims to be one. There is no mention of sculpting, rigging beyond keyframe animation, or a render engine.

How the editor is put together: Electron shell, web bundle, JavaScript plugins

The repository layout makes the architecture fairly plain. There is an electron/ directory and package.json sets "main" to electron/main.js, so the desktop build is an Electron wrapper around the same interface. There is also an index.html at the top level plus css/, js/, font/ and lib/ directories, and the README documents a separate command that serves the web app on a local port. The same editor therefore runs in two hosts.

The package.json declares "type": "module" and "engines": { "node": ">=20.0.0" }, so the source tree is ESM and expects a modern Node runtime. A build.js at the top level and a build/ directory handle packaging, and the electron-builder config inside package.json names dist-electron as the output directory and publishes through the GitHub provider. The Mac target is configured for both arm64 and x64 with hardened runtime and an entitlements plist, and the artifact name pattern is ${productName}_${arch}_${version}.${ext}.

Extension happens through JavaScript. The README states that "Blockbench supports Javascript-based plugins" and points to a plugin documentation page, and the repository carries a types/ directory and a typedoc.json, which is how the plugin API surface is published. Plugins are not sandboxed in any way the README describes. A plugin is a script with access to the editor API, so installing one is closer to running code than to toggling a feature.

Installing Blockbench and making a first model

Most people should not build from source. The README says plainly: "If you just want to use the latest version, please download the app from the website." The website is blockbench.net, which is also listed as the homepage in package.json.

If you do want to run it from source, the README gives two prerequisites and two commands. Install NodeJS first, then install dependencies:

npm install

To launch the desktop build in development mode, the README gives this command, and notes that Ctrl + Shift + B does the same thing:

npm run dev

To run the web app instead, the README gives a second command and states that the app is then reachable at http://localhost:3000:

npm run serve

For debugging, the README describes switching to the Run & Debug tab in VS Code, selecting the "Debug Renderer" configuration and pressing the green arrow, after which breakpoints work inside the editor.

Once the editor is open, the first real task is creating a model and exporting it. The README does not walk through the UI, so the honest instruction is to pick the format for your target platform at creation time, because the README says the Minecraft Java and Bedrock formats carry "format-specific features" that a generic format will not have. Exporting is then a matter of choosing a standardized format for sharing, rendering or 3D printing, or a Minecraft format for use in the game.

The plugin model is the real extension point, and the real risk

The README treats plugins as a first-class feature but says almost nothing about how they are loaded, versioned or isolated. What is documented is the language (JavaScript), the existence of a plugin API documentation page, and a licensing carve-out. The repository adds types/ and typedoc.json, so the API is typed and documented for authors, but the README does not describe a plugin manifest format, a compatibility range, or a review process.

That matters for adoption decisions. Plugins are external scripts that interact with the Blockbench API, and the README's licence section explicitly separates them from the GPL: "Plugins and themes can be created and/or published as open source, proprietary or paid software." So a paid plugin is permitted by the project's own licence statement. What is not stated anywhere in the README is what happens to that plugin when the API changes in a release. The recent releases listed are v5.2.0, described as "The Screen-Space Update", and v5.2.1 and v5.2.2, patches to it. A minor-version rename like that is exactly the kind of release that can move rendering and viewport behaviour, and the README documents no deprecation policy or migration guide for plugin authors.

Treat the plugin ecosystem as a convenience with an unpriced maintenance cost. If your pipeline depends on a plugin, you own the work of tracking API changes yourself.

Where Blockbench is the wrong tool

Blockbench is a low-poly editor, and the README says so in its first sentence. If your asset needs smooth organic surfaces, high-resolution textures, physics simulation or a film-quality render, this is the wrong program and no amount of plugin work changes that, because the constraint is in the model representation, not in the feature list.

The second limitation is subtler. The README presents the interface as both "beginner friendly" and full of "advanced features for experienced 3D artists". Those goals compete for screen space. A beginner-facing default layout and a deep customization layer usually mean the advanced path runs through settings, keymaps and plugin configuration rather than through the main viewport. The repository does include a keymaps/ directory, so remapping exists, but the README does not describe how much of the advanced workflow is reachable without configuration.

The third is licensing scope. The source is GPL-3.0-or-later per package.json and LICENSE.MD, and the README states that "Modifications to the source code can be made under the terms of that license." If you fork the editor itself and distribute it, the GPL applies to your fork. The plugin and theme exception does not extend to the core application. That distinction is the one people get wrong, and the README does not spell out the boundary beyond naming plugins and themes as the exception.

Alternatives and how the approach differs

Blender is the obvious comparison, and the difference is not quality, it is scope. Blender is a full 3D content suite: modelling with subdivision and sculpting, simulation, a node-based renderer, video editing. Blockbench is a single-purpose low-poly modeller that runs in a browser tab and understands Minecraft's export formats natively. If your deliverable is a Minecraft model, Blender makes you reconstruct the target format through an add-on and you still have to verify the output. If your deliverable is a rendered image or an animated short, Blockbench has nothing to offer you.

A second alternative is writing the model by hand. Minecraft Java models are JSON, and Bedrock models are JSON as well, so a text editor plus a script is a legitimate path for simple geometry. Blockbench wins as soon as you need to see UV mapping, because placing pixel-art texture islands by editing numbers is the part that does not scale. That is the specific problem the editor solves, and it is worth being precise about it: the value is in the viewport and the UV editor, not in the file format.

A third path is a general web-based 3D editor. Those exist, but they target generic glTF workflows, not the Minecraft-specific features the README attributes to the Java and Bedrock formats. If your pipeline is Minecraft, the format-specific features are the reason to pick Blockbench over a generic web editor.

Licence, maintenance and what an upgrade costs you

The source is licensed GPL-3.0-or-later, stated in both package.json and LICENSE.MD. Two consequences follow directly from the README's licence section. First, modifications to the source can be made under the terms of that licence, which means a distributed fork carries the GPL. Second, plugins and themes that interact with the Blockbench API are carved out and "can be created and/or published as open source, proprietary or paid software". Assets you create, which the README lists as "models, textures, animations, screenshots etc.", remain yours. That is a clean split, and it is unusually permissive for an editor of this kind. It is not legal advice; read LICENSE.MD yourself before shipping a fork or a commercial plugin.

On maintenance, the repository is not archived and the last push was on 2026-10-31; the latest release is v5.2.2, published on 2026-10-08. The release cadence visible in the repository is a minor release followed by two patches: v5.2.0 on 2026-09-18, v5.2.1 on 2026-09-21, v5.2.2 on 2026-10-08. That is a fast, frequent cadence, and frequent minor releases are the upgrade cost. If you pin a version for a studio pipeline, expect to re-verify plugin compatibility on each minor bump, because the README documents no stability guarantee for the plugin API and no rollback procedure. The README is also silent on migration between model format versions, so test exports against the target game version rather than assuming forward compatibility.

Editorial conclusion

Adopt Blockbench if you build low-poly, pixel-textured assets for Minecraft Java or Bedrock, or need a browser-based editor that runs without a native install. Do not adopt it as a general-purpose 3D suite: the README describes no sculpting, no retopology and no renderer for photoreal work, and the README documents no rollback or migration path for plugin API changes. Verify first that the format you need is actually supported, that your Node version is at least 20.0.0 if you build from source, and read the plugin and theme exception in LICENSE.MD before you decide how to license a plugin you intend to sell.

Frequently asked questions

Official sources

1. JannisX11/blockbench on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases