# loaders.wtf

By **dcp** · Software & Tools

Open-source file-format loaders for geospatial, tabular, and 3D data, with worker-thread and streaming support for big-data JS apps.

- Source: https://www.loaders.wtf/
- Tags: open-source, geospatial, data-loading, 3d, streaming, workers, visualization, javascript
- Pricing: free
- Upvotes: 0

## Features

- Unified load/save API across dozens of geospatial, tabular, and 3D formats
- Streaming incremental parsing via async iterators for files larger than memory
- Pre-built web workers for off-main-thread parsing on supported loaders
- Browser and Node.js LTS support with consistent behavior
- Composable module system: install only the format loaders you need
- Framework-agnostic output: plain JS objects and typed arrays
- Loader categories enforce standardized output shapes across similar formats
- Pre-integrated with deck.gl and other vis.gl frameworks

---

## Why it matters
Loading geospatial or 3D data in JavaScript is a format zoo: shapefiles, glTF, Arrow tables, CSVs, point clouds. loaders.gl (MIT, currently at v4) gives every format the same `load` / `loadInBatches` call, so switching formats does not rewrite your data pipeline.

## Module architecture
The library is split into a small `@loaders.gl/core` module and a range of optional format modules (CSV, Arrow, glTF, and more) that you install individually. Per the docs, each module exports loaders and writers with identical method signatures, so you can swap `CSVLoader` for `ArrowLoader` without touching the rest of your code. Crucially, some modules (like `@loaders.gl/arrow`) return columnar Arrow tables rather than row objects, which is a meaningful distinction for analytics pipelines that expect columnar memory layouts.

## Worker support
Many loaders ship pre-built web workers, moving parse work off the main thread entirely. One non-obvious gotcha noted in the architecture: worker-thread loaders rely on transferable typed arrays and modern browser security headers (COOP/COEP and SharedArrayBuffer access) for full performance. If your deployment cannot set those headers, loaders fall back gracefully but lose the off-thread benefit.

## Yes, but
loaders.gl is pre-integrated with deck.gl and the broader vis.gl ecosystem, which is genuinely convenient: deck.gl's internal `fetchFile` hooks and CORS handling are wired up out of the box. However, that tight coupling means the library is tuned around vis.gl usage patterns. If your only format is GeoJSON and you do not need workers or streaming, a lighter-weight library may avoid the module overhead entirely. loaders.gl earns its footprint when you need multi-format support, streaming, or worker offload.

## The bottom line
loaders.gl is the right call when your app must handle multiple geospatial or 3D formats at scale, tested at deck.gl production scale. Start at `loaders.gl/docs` to browse format modules, then install only the loaders your stack actually needs.

## FAQ

### What is loaders.gl?

loaders.gl is an open-source (MIT) JavaScript library at v4 that provides a unified API for loading and writing tabular, geospatial, and 3D file formats. It ships as a small core module plus optional format-specific modules (CSV, Arrow, glTF, Shapefile, and more), each returning parsed data as plain JavaScript objects or typed arrays. The library runs in browsers, Node.js LTS, and web workers, and comes pre-integrated with the deck.gl visualization framework.

### How do I install and use loaders.gl in my project?

Install `@loaders.gl/core` plus whichever format module you need (for example `@loaders.gl/csv`), then call `load('data.csv', CSVLoader)` to get a JavaScript array of row objects. For files larger than memory, use `loadInBatches` with an async iterator: `for await (const batch of await loadInBatches('data.csv', CSVLoader))`. The docs at loaders.gl/docs include a Get Started guide that walks through both patterns in TypeScript.

### Is loaders.gl free and open source?

Yes. loaders.gl is released under the MIT license, making it free to use, modify, and redistribute in both commercial and open-source projects. It is published as a suite of composable npm modules, so you only install the loaders your application actually needs.

### What is loaders.gl best for?

loaders.gl is best for JavaScript applications that must handle multiple geospatial or 3D file formats, especially when streaming large files or offloading parse work to web workers. It is the natural choice for teams building on deck.gl or other vis.gl frameworks, and for Node.js backend services that need the same format support as the browser client. If your app only consumes a single lightweight format like GeoJSON, a narrower library avoids the extra module weight.

### How does loaders.gl compare to format-specific libraries?

loaders.gl's core advantage over single-format libraries is a unified API: swapping `CSVLoader` for `ArrowLoader` (or a 3D loader) requires no changes to the surrounding data pipeline. Format-specific libraries often expose idiosyncratic APIs and offer no worker or streaming support. The tradeoff is that loaders.gl's module system adds some bundle overhead, and some modules (like `@loaders.gl/arrow`) return columnar Arrow tables rather than row objects, which can surprise developers expecting row-oriented output from every loader.

### What are the main limitations or gotchas?

Worker-thread parsing requires the browser deployment to set Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy (COOP/COEP) headers to enable SharedArrayBuffer; without those headers, loaders fall back to the main thread and you lose the off-thread benefit. The Arrow module returns columnar memory layouts, not row arrays, so downstream code must account for both output shapes. Pre-integration with vis.gl means the library is optimized for deck.gl usage patterns, which may not align perfectly with unrelated stacks. Finally, if your only format is GeoJSON and you need no workers or streaming, lighter alternatives will reduce bundle size.

---
[View on Analog](https://analoghq.ai/dcp/software-tools/loaders-wtf)