LAS is the uncompressed standard for LiDAR point clouds, LAZ is its losslessly compressed counterpart (typically 5-10x smaller), and E57 is the ASTM standard format designed for terrestrial laser scanners. For most drone and airborne LiDAR deliveries, deliver LAZ — it’s the same data as LAS but dramatically smaller, and every modern tool supports it. For terrestrial scanning projects, E57 is often the expected format because it supports multiple scan positions and scanner metadata that LAS cannot store. Here’s the full comparison.
I deal with all three formats regularly. The right choice depends on where the data came from, who’s receiving it, and what they plan to do with it.
Format comparison table
| Feature | LAS | LAZ | E57 |
|---|---|---|---|
| Full name | LASer file format | LASzip compressed LAS | ASTM E2807 |
| Developed by | ASPRS | Martin Isenburg (rapidlasso) | ASTM International |
| Standard | ASPRS LAS 1.0-1.4 | LASzip (open source) | ASTM E2807-11 |
| Compression | None | Lossless (LASzip) | Basic internal compression |
| Typical compression ratio | 1x (baseline) | 5-15x smaller than LAS | 2-5x smaller than equivalent LAS |
| Data loss | N/A | None (lossless) | None |
| Multiple scan positions | No | No | Yes |
| Scanner metadata | No | No | Yes (position, serial, settings) |
| Embedded images | No | No | Yes (panoramic scanner images) |
| Coordinate types | Cartesian (XYZ) | Cartesian (XYZ) | Cartesian + Spherical |
| Classification codes | ASPRS standard (0-255) | ASPRS standard (0-255) | Limited classification |
| Current version | 1.4 (2011) | Matches LAS version | Revision 2011 |
| Industry | Airborne LiDAR, UAV, photogrammetry | Same as LAS | Terrestrial scanning |
LAS: the uncompressed baseline
What it is
LAS (LASer) is the open format standard for LiDAR point cloud data, maintained by ASPRS (American Society for Photogrammetry and Remote Sensing). It was first published in 2003 and has been the dominant format for airborne and UAV LiDAR data exchange ever since.
Every point in a LAS file stores XYZ coordinates plus optional attributes: RGB colour, intensity, return number, classification, GPS time, and scan angle. The ASPRS classification codes are well-established — ground (2), low vegetation (3), medium vegetation (4), high vegetation (5), building (6), and so on.
File sizes
LAS files are uncompressed and therefore large. Each point record is typically 20-36 bytes depending on the point format (LAS defines several point record formats with different attribute combinations).
| Dataset | Point count | LAS size | Points per sq metre |
|---|---|---|---|
| Small drone survey (5 ha) | 50 million | ~1.5 GB | ~100 |
| Medium site (50 ha) | 500 million | ~15 GB | ~100 |
| Large airborne LiDAR (1000 ha) | 2 billion | ~60 GB | ~20 |
| Dense terrestrial scan (single room) | 100 million | ~3 GB | ~10,000+ |
These sizes are why LAS is rarely used for delivery or transfer. You process in LAS, you archive in LAS, but you deliver in LAZ.
Pros
- Universal compatibility — every point cloud tool supports LAS
- No decompression step — opens immediately
- Well-defined classification standard
- Open specification maintained by ASPRS
Cons
- Large file sizes make transfer and storage expensive
- No compression means wasted bandwidth and disk space
- No support for multiple scan positions
- No embedded imagery or scanner metadata
LAZ: lossless compressed LAS
What it is
LAZ is a losslessly compressed version of LAS, developed by Martin Isenburg and implemented in the open-source LASzip library. A LAZ file contains exactly the same data as the equivalent LAS file — every point, every attribute, every bit of precision. Nothing is lost or approximated.
The compression is typically excellent: LAZ files are 5-15x smaller than their LAS equivalents, depending on the data characteristics. Dense, regular data (airborne LiDAR) compresses better than sparse, noisy data (photogrammetry point clouds).
I wrote a detailed explainer on the format: What is a LAZ File?
File sizes
| Dataset | LAS size | LAZ size | Compression ratio |
|---|---|---|---|
| Small drone survey (5 ha) | ~1.5 GB | ~150-250 MB | 6-10x |
| Medium site (50 ha) | ~15 GB | ~1.5-2.5 GB | 6-10x |
| Large airborne LiDAR (1000 ha) | ~60 GB | ~5-8 GB | 8-12x |
| Dense photogrammetry cloud | ~3 GB | ~500-800 MB | 4-6x |
The compression ratio depends on the data. Airborne LiDAR with regular scanning patterns compresses better (10-15x) than photogrammetry point clouds with more random point distributions (4-8x).
Pros
- Dramatically smaller files — 5-15x compression with zero data loss
- Universal support — every modern point cloud tool reads LAZ
- LASzip is open source and free
- Same data as LAS — decompresses to identical bytes
- Faster transfer and lower storage costs
Cons
- Requires decompression to process (minimal overhead with modern hardware)
- Some very old tools don’t support LAZ (increasingly rare)
- Still limited to Cartesian coordinates and single-scan-position structure
When to use LAZ
Almost always. If your data originated as LAS (airborne LiDAR, UAV LiDAR, photogrammetry point cloud), deliver it as LAZ. There is no practical reason to deliver uncompressed LAS unless the client explicitly requests it or is using legacy software that doesn’t support LAZ.
E57: the terrestrial scanning standard
What it is
E57 is a file format standard published by ASTM International (ASTM E2807) for storing 3D point cloud data and associated metadata, primarily from terrestrial laser scanners. It was designed specifically to address limitations of LAS for terrestrial scanning workflows.
I covered E57 in depth here: What is an E57 File?
The key capabilities that distinguish E57 from LAS/LAZ:
Multiple scan positions in one file
A terrestrial scanning project might involve 50-200 scanner setups across a building or site. In LAS, you’d have 50-200 separate files (or one merged file with no scan position information). In E57, all scan positions can be stored in a single file, each with its own:
- Scanner position and orientation
- Scan resolution and range
- Registration transform (how the scan aligns with the others)
- Associated panoramic images (if the scanner captures them)
This is significant for workflows that need to trace data back to individual scan positions — common in forensics, heritage documentation, and quality assurance.
Spherical coordinates
Terrestrial scanners natively capture data in spherical coordinates (azimuth, elevation, range relative to the scanner). E57 can store data in either spherical or Cartesian coordinates — or both. LAS supports only Cartesian.
Embedded scanner images
Many terrestrial scanners (Leica RTC360, Faro Focus, etc.) capture 360-degree panoramic images at each scan position. E57 can embed these images directly in the file alongside the point cloud data.
File sizes
E57 files include internal compression but it’s generally less aggressive than LASzip:
| Dataset | E57 size | Equivalent LAZ size |
|---|---|---|
| Small interior scan (10 positions) | ~2-5 GB | ~1-3 GB (merged) |
| Medium building (50 positions) | ~10-30 GB | ~5-15 GB (merged) |
| Large site (200 positions) | ~50-100 GB | ~20-50 GB (merged) |
E57 files tend to be larger than equivalent LAZ because they carry additional metadata (scanner positions, images, spherical coordinates). But comparing raw size is misleading — E57 carries more information per file.
Pros
- Industry standard for terrestrial scanning
- Multiple scan positions with full metadata
- Embedded panoramic images
- Spherical coordinate support
- Supported by all major scanner vendor software
Cons
- Larger files than LAZ for equivalent point count
- Less compression than LASzip
- Classification support is limited compared to ASPRS standards in LAS
- Some tools have inconsistent E57 support (especially open-source tools)
- Not widely used outside terrestrial scanning
When to use E57
When your data comes from a terrestrial laser scanner and the recipient needs scan position information, scanner metadata, or embedded panoramic images. If you’re delivering a merged, classified point cloud from a terrestrial scanning project and the client doesn’t need per-scan metadata, converting to LAZ is often more practical.
Practical delivery guidance
For drone / UAV surveys
Deliver LAZ. Your photogrammetry software (Pix4D, Metashape, DJI Terra) exports LAS by default. Compress to LAZ before delivery. Every tool your client might use supports LAZ, and the file will be 5-10x smaller.
# Convert LAS to LAZ using LAStools
laszip -i input.las -o output.laz
# Or using PDAL
pdal translate input.las output.laz
For airborne LiDAR
Deliver LAZ. Same reasoning as drone surveys. The ASPRS classification codes in LAS/LAZ are the standard for airborne data.
For terrestrial scanning
Ask the client what they need. If they’re working in Leica Cyclone, Faro SCENE, or Autodesk ReCap, deliver E57. If they just want a viewable point cloud, LAZ of the merged/registered point cloud is more portable.
For projects where you’re delivering both the registered E57 (for the client’s scanning team) and a viewable point cloud (for the project manager), deliver both: E57 for the technical team, and a LAZ or browser-based viewer link for everyone else.
For client viewing (non-technical recipients)
Don’t deliver a file at all — deliver a viewer link. Non-technical clients don’t have CloudCompare, QGIS, or Cyclone. Send them a link that opens the point cloud in their browser.
Platforms like Swyvl accept LAS, LAZ, and E57 uploads and generate browser-based Potree viewers automatically. Upload the file, share the link, and the client views the point cloud without installing anything. I wrote about this approach in detail: How to Share LAS Files with Clients.
Converting between formats
LAS to LAZ (and back)
This is a lossless round-trip. Convert freely.
# LAS → LAZ
laszip -i input.las -o output.laz
# LAZ → LAS
laszip -i input.laz -o output.las
PDAL, CloudCompare, and most GIS tools can also do this conversion.
E57 to LAS/LAZ
Converting E57 to LAS/LAZ is straightforward but loses E57-specific metadata:
- Scanner positions are discarded (all points merge into one dataset)
- Spherical coordinates are converted to Cartesian
- Embedded panoramic images are lost
- Per-scan metadata is dropped
The point coordinates, colours, intensity, and normals survive the conversion.
# E57 → LAZ using CloudCompare CLI
CloudCompare -SILENT -O input.e57 -C_EXPORT_FMT LAS -SAVE_CLOUDS
CloudCompare, PDAL, and Autodesk ReCap can all handle this conversion.
LAS/LAZ to E57
Converting LAS to E57 creates a valid E57 file but without the scanner metadata that gives E57 its value. The result is essentially LAS data in an E57 container. Generally not useful unless a downstream tool specifically requires E57 input.
Browser viewing compatibility
All three formats can be viewed in a browser — but the pathway differs:
| Format | Browser viewing approach | Viewer |
|---|---|---|
| LAS/LAZ | Convert to Potree octree format (PotreeConverter) | Potree |
| LAS/LAZ | Convert to 3D Tiles (via py3dtiles or similar) | CesiumJS |
| E57 | Convert to LAS/LAZ first, then to Potree or 3D Tiles | Potree or CesiumJS |
None of these formats can be loaded raw into a browser — they all require preprocessing into a streaming format. The conversion step is where platforms like Swyvl add value: you upload the raw file and the platform handles the conversion and hosting automatically.
My recommendation
For the vast majority of survey deliveries, this is the decision:
- Is it from a terrestrial scanner and the client needs scan position data? Deliver E57.
- Everything else? Deliver LAZ.
- Is the recipient non-technical? Deliver a browser viewer link alongside (or instead of) the file.
Don’t deliver uncompressed LAS unless specifically asked. The 5-15x file size difference between LAS and LAZ is significant for transfer time, storage cost, and the client’s patience. LAZ decompresses transparently in every modern tool — there’s no reason to inflict multi-gigabyte downloads on anyone.
And if your client’s primary need is to see the data, not to process it in GIS software, skip the file delivery entirely and send them a shareable viewer link. A project manager exploring a point cloud in their browser in 30 seconds is always better than a project manager staring at a 2 GB download wondering what to do with it.
For more on professional delivery workflows, see How to Deliver Drone Survey Data to Clients Professionally.