loaders.gl: framework-independent loaders for big data visualisation

A parsing layer that does not care about your renderer

loaders.gl is described as a collection of framework-independent loaders for geospatial, 3D and large data visualisation, and it is part of the vis.gl umbrella.

The word framework-independent is the whole design. A typical application that shows a map or a 3D scene ends up with its file parsing welded to its rendering library, so replacing the renderer means rewriting the loading code. loaders.gl separates the two: the loader turns bytes into data structures, and the renderer is your choice.

The package structure follows that idea. The project is published on npm as a family of packages, with the core package exposed as @loaders.gl/core, and the repository is a monorepo whose workspaces cover the modules, the apps, the examples and the website.

The audience is engineers building web based visualisation, particularly with the deck.gl, luma.gl or vis.gl family, but also anyone who has ever written a glTF parser and wished they did not have to.

The documentation lives on the loaders.gl website rather than in the repository readme, and the readme is deliberately short: a description, a link to the docs, a contributing pointer, the build and test workflows, and the licence statement.

The format range, from glTF to geospatial tables

The repository topics list is the clearest catalogue of what the collection covers: 3D Tiles, Apache Arrow, Apache Parquet, CSV, Draco, GeoArrow, GeoParquet, glTF, I3S, LAS, PLY, OBJ, WKB, WKT, plus the general labels of streaming and workers.

It helps to see this as three overlapping groups.

The 3D graphics group covers glTF and its binary variant, Draco compression, PLY and OBJ point clouds and meshes, 3D Tiles for streamed tiles of large scenes, and I3S, the Esri 3D standard. The package.json keyword list matches this group, naming GLB, OBJ, PLY, LAZ, PCD and KML.

The geospatial group covers GeoJSON-style vector data through WKB and WKT, GeoArrow and GeoParquet, LAS and its compressed LAZ variant, and I3S.

The big data group is the newer direction: Apache Arrow and Apache Parquet, which is what lets a visual application read the same columnar files an analytics stack produces, and CSV as the universal fallback.

That last group is the strategically interesting one. A tool that reads Parquet and GeoParquet directly is aimed at applications where the data pipeline ends in a file format designed for analysis rather than for drawing, and where the visual layer should not require a conversion step.

Workers and streaming, and the range server

Two entries in the topics list are not formats at all: workers and streaming. They describe how the loaders are meant to be used with data too large to hold comfortably.

The build workflow has a dedicated step for the worker bundles. The README says to run yarn build to build the modules and then yarn build-workers to generate the worker bundles, and to rebuild the workers after each module build. That ordering note matters, because a worker bundle compiled against an older module build produces confusing failures rather than an obvious one.

The streaming side shows up in the scripts. There is a serve-range command that runs a small range server, which is the standard way to exercise HTTP range requests against local files, and range requests are how you read a large tiled dataset without downloading all of it.

The scripts section of package.json makes the build system legible:

    "build": "yarn build-modules",
    "build-modules": "node ./scripts/build-modules-parallel.mjs",
    "build-apps": "node ./scripts/run-app-commands.mjs build",
    "build-workers": "node ./scripts/build-workers.mjs",

So the module build runs in parallel through a dedicated script, the apps have their own runner, and the workers are a separate build product rather than a side effect. The scripts are Node ES modules, matching the package type field, and the whole project declares ES modules throughout.

For tooling, the project leans on ocular: ocular-bootstrap, ocular-clean, ocular-lint and ocular-publish for beta and production releases. Linting and formatting go through biome rather than a hand written eslint configuration, and vitest is the test runner.

The monorepo, the apps and the examples

The top level of the repository explains how the project is organised, and it is worth a look before you clone it.

The modules directory holds the published packages, with a formats directory alongside it. The apps directory contains applications built on the modules, and the README notes that there is currently only one app in the repository, the tile converter, which is what the build-apps and test-apps scripts act on. The examples directory holds several groups, including experimental examples, a gallery, a getting started set, a lance example and a website example.

There is also a dev-modules directory and a dev-docs directory for internal tooling, a website directory for the documentation site, a docs directory with the developer guide, and a test directory. The developer environment guide at docs/developer-guide/dev-env.md is where the runtime requirements and browser setup are described, which is the file to read before a first build.

The package manager is pinned. The packageManager field names yarn 4.17.1 with a checksum, the repository ships a .yarn directory and a .yarnrc.yml, and there is an .nvmrc for the Node version. The engines field accepts Node 22.13, 24 or 26.

  "workspaces": [
    "modules/*",
    "apps/*",
    "examples/**",
    "website"
  ],
  "engines": {
    "node": "^22.13.0 || ^24.0.0 || ^26.0.0"
  },

One structural note for contributors: the repository also contains a skills directory and an AGENTS.md file, which suggests that part of the contributor workflow has been written for automated agents rather than only for humans.

The build and test workflow in practice

The README lists the workflows explicitly, and the sequence is the one to follow.

Start with yarn install to install the workspace dependencies. Then yarn build to build the modules, and yarn build-workers to generate the worker bundles, with the instruction to rebuild the workers after each module build.

Testing is split by environment. yarn test-node runs the Node.js tests and yarn test-headless runs the Chromium tests, and yarn test runs both. The package.json gives the same split a different shape: the test script invokes a runner with the full argument, test-modules does the same, test-node passes the node argument, and there are dedicated targets for the tile converter and for the browser run.

For housekeeping there is yarn lint fix to apply lint and formatting fixes, and yarn test-website to install the website dependencies and build the documentation site, which is the check to run before opening a documentation pull request.

The apps have their own pair of commands, yarn build-apps and yarn test-apps, described as running the tile converter app build and exercising its test script when available. The conditional wording of that last one tells you the app test is not always present.

Nothing in this workflow requires anything beyond Node and a browser, but the Node version range is narrow enough to matter: 22.13, 24 and 26 are accepted, and other versions are not.

Versioning, licensing and where the project fits

The release tags show two tracks running at once: v4.5.4 published on 2026-10-10, v5.0.0-alpha.12 on 2026-10-13 and v5.0.0-alpha.11 on 2026-10-09, with the last push on 2026-10-20. So the stable line is receiving patch releases while the 5.0 line is still in alpha and moving quickly.

That is worth understanding before you pin a version. The alpha tags are for testing the next major version, and the beta and production publish scripts in package.json show that the project distinguishes the two in its release pipeline.

On licensing, the README states that loaders.gl uses the MIT licence, while the repository also carries a LICENSE file and a NOTICE file. The important nuance is the second paragraph: some individual loaders are forked from other open source code bases under different but compatible permissive licences such as Apache 2 or BSD, and the README states that no code using proprietary, copy-left or non-permissive licences is included. It also tells you where to look, an attributions section for each loader module, before you install it if the details matter to you. That is a more useful licence story than a single file name, because the per module attributions are what tell you what you are actually shipping.

The alternative to this project is writing or adopting a parser per format, which is what most teams do before they find loaders.gl. The other alternative is a framework bound loader, such as the ones shipped inside a specific rendering library, which is simpler to start with but couples your data layer to a renderer you may want to change. loaders.gl sits between the two: more setup than a single purpose parser, less coupling than a framework loader, and a single place to pick up support for a format that was never designed for the web.

Editorial conclusion

loaders.gl is the right choice when your application has to read geospatial or 3D data it did not produce, because it keeps the parsing layer separate from the rendering layer and lets you swap the renderer without touching the format handling, and its worker bundles keep large files off the main thread. It is the wrong choice for a project that reads exactly one format, since a single purpose parser is usually smaller, and it is the wrong choice if you need a guarantee of long term API stability, because the 5.0 line is still in alpha while the 4.5 line carries the production releases. Verify first which format modules you actually need, check the attributions section of each module for its licence, and pin the 4.x version rather than tracking the alpha tags.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. visgl/loaders.gl on GitHub