LAS vs LAZ vs E57 (and COPC): Which File Type to Deliver?

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. E57 is also the only one of the three that can carry the 360° photos a scanner takes at each setup. COPC, the fourth name you will see, is not a separate file type: it is a LAZ arranged so it streams in a browser. 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

Want to try it now? Open a LAS, LAZ or PLY file in the browser, or check what is inside an E57. Free, no signup, and your file stays on your computer.

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 color, 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).

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

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:

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 the embedded 360° photos. The photos are the part people underestimate: a 360° photo on its own has no scale, so you cannot measure on it, and a point cloud on its own is hard to read up close. In an E57 they line up, so a viewer can let you measure and pin notes on what the photo shows. More in why deliver an E57 with its 360° photos.

If you’re delivering a merged, classified point cloud and the client doesn’t need per-scan data or photos, converting to LAZ is often more practical.

COPC: LAZ that streams

COPC (Cloud Optimized Point Cloud) is a LAZ 1.4 file with the points organized into an octree, so a viewer can fetch only the part on screen over HTTP range requests. Every LAZ reader still opens it as a normal LAZ. You rarely deliver COPC as such; it is what a browser viewer streams. If you host your own viewer, convert to COPC; if you use a platform, it does this on upload.

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 want a point cloud for GIS or CAD, a LAZ of the merged, registered cloud is more portable. If they mostly want to look, deliver the E57 with its 360° photos as a browser link: it is the most readable thing you have.

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, convert them to COPC and open them in a browser-based Potree viewer automatically. Upload the file, share the link, and the client views the point cloud without installing anything. With an E57, the 360° photos come too. 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, colors and intensity survive the conversion. Normals survive only if the tool writes them as extra dimensions, because LAS has no normal field.

# E57 → LAZ using PDAL 2.10+ (millimeter coordinates)
pdal translate input.e57 output.laz --writers.las.compression=true \
  --writers.las.scale_x=0.001 --writers.las.scale_y=0.001 --writers.las.scale_z=0.001

# E57 → LAZ using CloudCompare CLI
CloudCompare -SILENT -O input.e57 -C_EXPORT_FMT LAS -SAVE_CLOUDS

CloudCompare, PDAL, LAStools (e572las) and Autodesk ReCap can all handle this conversion. Full recipes, including COPC: convert E57 to LAS, LAZ or COPC with PDAL.

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:

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.

What Swyvl does with each

In every case the original stays in your workspace, and the client can download it if you set the link to allow it. On any point cloud the client can measure point, distance, area and height; on an E57 with 360s they can also measure from the photos, where the detail is easier to see. You can pin notes (with a sketch drawn over the view) in the cloud or in a photo, and clients you invite by email reply on them, free, with no account. Notes stay with the place, so on georeferenced scans they show on the next scan of the site too. Files up to 100 GB each.

My recommendation

For the vast majority of survey deliveries, this is the decision:

1. Is it from a terrestrial scanner and the client needs scan position data or the 360° photos? Deliver E57, exported with its images.
2. Everything else? Deliver LAZ.
3. Is the recipient non-technical? Deliver a browser viewer link alongside (or instead of) the file. For a terrestrial scan, make it the E57, so they get the photos too.

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.