LiDAR data ships in a small family of file formats with overlapping but non-identical capabilities. Picking the right one at handoff is the difference between a deliverable your team can ingest directly and one that needs a round of conversion before anyone can do anything with it.
If you've ever received a LiDAR delivery, opened the first file and discovered your software doesn't read it, you've met the LiDAR file-format question. The good news: there are only four or five formats that really matter. The bad news: each has versions, profiles and edge cases that affect what's actually inside the file.
This article is the practical reference. What each format is, what it carries, which one to ask for, and the tooling that reads each.
LAS — LASer file format is the ASPRS-published binary format that has been the working standard for LiDAR exchange since the early 2000s. Virtually every commercial and open-source spatial tool reads LAS natively, and virtually every LiDAR provider delivers LAS as the primary cloud format.
The structure of a LAS file is straightforward:
The version number on the file matters. The five LAS versions have meaningful differences:
| Version | Year | Key additions | | ------- | ------ | ------------------------------------------ | | 1.0 | 2003 | The original | | 1.1 | 2005 | Classification flag bits | | 1.2 | 2008 | RGB colour per point (PDR format 2) | | 1.3 | 2010 | Waveform data (PDR format 4, niche) | | 1.4 | 2011 | 256 classes, 64-bit point count, OGC WKT |
LAS 1.4 is the current standard and what every new capture should ship as. The big additions in 1.4:
A delivery quoting "LAS" without a version number is almost certainly LAS 1.2 or 1.4. Worth confirming which.
The PDR format dictates what attributes each point carries. LAS 1.4 supports formats 0 through 10:
| PDR | Attributes | | --- | ----------------------------------------------------- | | 0 | XYZ, intensity, return number, scan angle | | 1 | + GPS time | | 2 | + RGB colour (no GPS time) | | 3 | + RGB colour + GPS time | | 4 | + waveform data (niche) | | 5 | + RGB + waveform | | 6 | LAS 1.4 — extended fields, 64-bit pt count baseline | | 7 | 6 + RGB | | 8 | 7 + NIR (4th colour channel for vegetation analysis) | | 9 | 6 + waveform | | 10 | 7 + waveform + NIR |
For typical engineering work, PDR 6 or 7 is what you want (LAS 1.4, with or without colour). PDR 3 (LAS 1.2 with RGB and GPS time) is also fine. Older PDR formats lack GPS time, which makes them inadequate for projects that need temporal correlation of returns.
LAZ is the compressed version of LAS, developed by rapidlasso (Martin Isenburg's team). It's lossless — a LAZ file contains exactly the same information as the equivalent LAS file — and typically delivers 7–20× compression.
Why this matters:
Modern tools (CloudCompare, LASTools, PDAL, QGIS, ArcGIS Pro, 12d, Civil 3D recent versions) read LAZ directly without intermediate decompression. Older tools sometimes need explicit decompression to LAS first.
The current LAZ format is LAZ 1.4 matching LAS 1.4; older tools may only read LAZ 1.2.
For most projects, LAZ is the right delivery format and LAS is the fallback for any consumer tool that doesn't read LAZ directly.
E57 is an ASTM-published binary format designed for multi-sensor data — LiDAR points alongside imagery, intensity data and structured metadata. It's the working standard in terrestrial laser scanning (Leica, Trimble, FARO scanners ship in E57 natively) and increasingly relevant for projects that combine LiDAR with paired imagery.
For drone topographic LiDAR, E57 is less common but supported by some pipelines (particularly hybrid LiDAR + camera workflows where the camera imagery needs to travel with the cloud). For pure topographic work, LAZ is usually preferred.
E57 strengths:
E57 weaknesses:
COPC — Cloud Optimized Point Cloud is a more recent format (2022) designed for streaming-friendly access to large LiDAR clouds in cloud-native workflows.
The mechanism: COPC is a LAZ 1.4 file with an octree spatial index baked into the file header. The octree lets a client request a specific region or level-of-detail without downloading the entire cloud — analogous to how COG (Cloud Optimized GeoTIFF) works for rasters.
Why this matters:
For project deliverables intended for web-based viewing or streaming workflows, COPC is a strong choice. For traditional desktop workflows it's compatible with everything LAZ supports.
Beyond the file format itself, three structural choices affect how a LiDAR delivery is organised:
1. Single file vs tiled. Small captures (under 100 million points) can ship as a single LAS / LAZ file. Larger captures ship as a tile set — typically 500 m × 500 m or 1 km × 1 km tiles aligned to a regular grid. Tiled deliveries open one tile at a time in the GIS / CAD tool rather than loading several GB at once.
2. Project header file. A project-level metadata file (often JSON or XML) accompanying the tile set, documenting the tile grid, file naming convention, datum, classification scheme and QA report references. Essential for large deliveries; optional for small.
3. Naming convention. Tile filenames typically encode the
tile coordinates or grid reference — e.g., LiDAR_2026_E12345_N67890.laz
or tile_055_023.laz. The convention should be documented in
the project header so downstream tools can compute tile lookups.
For projects over ~50 million points, tiled delivery is the working norm. The default tile size depends on intended use — 500 m for detailed engineering work, 1 km for regional context, 2 km for very large captures where loading time dominates over detail navigation.
Six tools every spatial team should know about:
LASTools (rapidlasso) — the commercial gold standard for LAS / LAZ processing. lasinfo, lasview, lasmerge, lasthin, lasground, lasclassify and a few dozen others. Each tool is a command-line utility doing one thing well. License required for production use.
PDAL (Point Data Abstraction Library) — open-source pipeline toolkit. Compose processing as a JSON pipeline definition; extensive filter and reader catalogue; works with LAS / LAZ / COPC / E57 and most other point formats. Free.
CloudCompare — open-source desktop viewer and editor. Open LAS / LAZ / E57 files, inspect classification, run basic processing, export to other formats. Free. Best for visual QA and one-off processing.
QGIS / ArcGIS Pro — both have native LAS / LAZ ingestion since the late 2010s. Native viewing, classification visualisation, basic profiling. Good for GIS workflows where the LiDAR sits alongside other spatial layers.
12d Model + Civil 3D — engineering CAD tools. Both ingest LAS / LAZ directly; 12d has stronger native handling. Both support tiled deliveries via project-level configuration.
TerraScan + TerraModeler (Terrasolid) — the commercial processing pipeline most engineering survey shops use for classification, surface modelling and deliverable generation. Runs inside MicroStation; not for end-user delivery but worth knowing as the upstream tool.
The clean format specification at scoping:
A delivery specified this cleanly avoids the post-delivery round trip of "can you re-export in [other format]?" that costs both sides a day.
Three patterns we see in marginal projects:
Delivery in LAS 1.2 when the project needed LAS 1.4. A classification scheme using ASPRS classes 13-18 (wires, towers, rail features) doesn't fit in LAS 1.2's 5-bit class field. The classes get coerced into the available range, losing the distinction. Specify LAS 1.4 at scoping if your classification uses the extended schema.
Single multi-GB LAS file for a large capture. Loading a 20 GB LAS file in any desktop tool is painful. Tiled delivery solves this; should be the default above a few-million-point threshold.
No project header / manifest. The tiles are there, the filenames are consistent, but no document explains the grid, the datum or the classification. Downstream consumers have to infer everything from file inspection. A two-page manifest eliminates this.
LAS 1.4 is the format; LAZ is the compression; COPC adds streaming; E57 is the multi-sensor alternative; tiled delivery above ~50 million points; project header always.
Specify all four (format + compression + structure + manifest) at scoping and the delivery lands ingestion-ready. Leave any one unspecified and the post-delivery cleanup work falls on your team — typically a day or two of conversion and re-organisation that the original capture could have done inline at near-zero marginal cost.
Tell us the consumer tools (Civil 3D, 12d, Bentley, ArcGIS, custom pipeline) and the project scale. We'll spec format + compression + tile structure + manifest at quote time so the delivery opens cleanly on arrival.
How LAS / LAZ sit alongside the other 11 deliverables (DTM, DSM, contours, CAD, BIM, etc.) in the standard deliverable catalogue.
The classification schema that drives the choice between LAS 1.2 (32 classes) and LAS 1.4 (256 classes).