On January 23, MapLibre announced MapLibre Tile (MLT), a next-generation vector tile format that replaces the industry-standard Mapbox Vector Tile (MVT) used for the past decade. MLT delivers 6x better compression on large tiles and 2-3x faster browser decoding through a column-oriented design optimized for WebGPU. Vector tiles power every interactive web map—from OpenStreetMap viewers to geospatial dashboards—and this is the first major format upgrade since 2014.
The timing matters. MVT was designed when WebGL was just becoming standardized. With WebGPU now achieving 70% browser support and geospatial data volumes exploding (planet-scale maps, 3D terrain, linear referencing), MVT’s row-based encoding has hit its limits. MLT is the infrastructure upgrade the ecosystem needed. Learn more from the official MapLibre Tile announcement.
6x Smaller Tiles, 2-3x Faster Rendering
MLT achieves up to 6x better compression on large tiles through a column-oriented layout with recursive lightweight encodings. Instead of storing Feature 1 (all attributes) → Feature 2 (all attributes) like MVT does, MLT stores all “name” values together, all “population” values together, all geometries together. This architectural shift enables aggressive compression because similar data types cluster naturally.
The format applies multiple compression techniques in sequence: delta encoding for numeric sequences, dictionary encoding for repeated strings, run-length encoding for consecutive values. Browser decoding is 2-3x faster even without SIMD optimizations because these encodings are compatible with vectorization instructions. Furthermore, the in-memory representation loads directly into GPU buffers with minimal preprocessing—critical for WebGPU performance.
A planet-scale map that previously required 10 TB of MVT tiles might now fit in 1.6 TB with MLT. Mobile users on slow connections see drastically faster loading. CDN costs drop for high-traffic mapping applications. The academic paper on MLT architecture provides detailed performance benchmarks.
WebGPU and the Death of Row-Based Encoding
MVT was created during the Mapbox GL era when WebGL was two years post-standardization. It worked brilliantly for its time, but row-based encoding can’t leverage modern GPU architectures. When MapLibre forked from Mapbox in December 2020—after Mapbox v2 became proprietary—the community gained independence to rethink the format entirely.
WebGPU achieved full cross-browser support in January 2026 (Firefox 147, Safari iOS 26/macOS Tahoe 26, Chrome), hitting 70% browser penetration. The API delivers 15-30x performance improvements over WebGL for compute workloads. MLT was designed specifically for this: GPU-optimized storage, SIMD-compatible encodings, minimal preprocessing overhead.
Meanwhile, geospatial data volumes exploded. Planet-scale OpenStreetMap datasets, 3D building models, Overture Maps with linear referencing, real-time IoT streams—MVT’s 2014 architecture wasn’t built for this scale. Consequently, MLT addresses all of it: support for 3D coordinates (elevation/z-values), m-values for linear referencing, complex nested types (lists, maps).
Column-Oriented Like Parquet, But for Maps
Column-oriented encoding isn’t new—Apache Parquet did it for big data, Arrow for analytics. Now MLT brings the same proven approach to geospatial data. The performance gains are mechanical: storing similar data together enables better compression and faster processing. In fact, it’s the industry standard move when data volumes explode.
Developers familiar with Parquet or modern database engines will immediately understand MLT’s advantage. This isn’t exotic—it’s applying established techniques to a domain that needed them. Moreover, the technical specification is available on GitHub with reference implementations in Java, TypeScript, Rust, and C++.
Related: PostgreSQL Performance 2026: 94% Faster, 13x vs MySQL
The column-oriented shift mirrors what’s happening across the data infrastructure stack. PostgreSQL’s recent performance leap came partly from columnar optimizations. MLT applies the same logic to vector tiles.
Production-Ready Today, Migration Path Clear
MLT is production-ready. MapLibre GL JS and MapLibre Native already support it via a simple property change:
{
"sources": {
"my-vector-source": {
"type": "vector",
"encoding": "mlt",
"tiles": ["https://example.com/tiles/{z}/{x}/{y}.mlt"]
}
}
}
That’s it. Change encoding: "mvt" to encoding: "mlt". The specification reached stable status in October 2025, focusing on MVT feature parity—MLT is a drop-in replacement for most use cases.
Encoding servers can convert MVT to MLT on-the-fly, enabling gradual migration without regenerating tile sets immediately. Test performance with existing tiles, then commit when Planetiler (the leading OpenStreetMap vector tile generator) ships MLT support in its upcoming release. Early adopters get benefits now; mainstream adoption depends on tooling maturity.
When to Switch
For new projects starting in 2026, use MLT from day one. The performance benefits are clear, browser support is there, and client libraries are ready. However, for existing applications, the decision is more nuanced.
Regenerating planet-scale tile sets is expensive—compute, storage, time. Nevertheless, 6x compression and faster decoding create strong incentives, especially for high-traffic applications where CDN costs matter and mobile users dominate. Third-party tile providers don’t support MLT yet (most remain MVT-only), so you’ll need control over tile generation.
One technical consideration: MLT enforces stricter attribute type consistency than MVT. You can’t mix strings and numbers in the same column. If your GeoJSON has inconsistent types (common in legacy data), clean your data schema before encoding.
Key Takeaways
- MLT delivers 6x better compression on large tiles and 2-3x faster browser decoding through column-oriented encoding and GPU-optimized design
- WebGPU’s 70% browser support (January 2026) makes MLT’s architecture perfectly timed for modern graphics APIs
- Production deployment is straightforward: change the
encodingproperty in MapLibre GL JS sources, regenerate tiles when Planetiler ships MLT support - New projects should use MLT immediately; existing apps should test with encoding servers before committing to regeneration
- Column-oriented encoding is the industry standard move for large-scale data—MLT brings proven database techniques to geospatial infrastructure
The shift from MVT to MLT mirrors the HTTP/2 transition: invisible to end users but transformative for performance and scale. MapLibre’s independence from Mapbox enabled this redesign, and the timing—WebGPU adoption, data volume explosion, tooling maturity—couldn’t be better. MVT will persist for years (like HTTP/1.1), but the direction is clear.










