LAS and LAZ hold the same lidar data. LAS is the uncompressed ASPRS format for point clouds, and LAZ is its losslessly compressed version produced by LASzip. The question is not which format keeps more information, because they keep exactly the same information, but where the cost should fall: on disk space or on processor time.

LAS vs LAZ: What Is the Difference?

A LAS file stores every point record as a fixed-length block of bytes, so software can jump to any point by calculating its offset. LAZ keeps the same header and the same point attributes, but compresses the point records into chunks, so the file becomes several times smaller and every read has to decompress the chunk that contains the requested points.

LAS vs LAZ

What Is LAS?

LAS is the binary exchange format for lidar published by ASPRS; the current specification is version 1.4, revision 15. A file consists of a header, variable length records that carry metadata such as the coordinate system, and the point records themselves.

What each point contains is defined by the point data record format, numbered 0 to 10. The earlier formats add GPS time and RGB colour to the basic coordinates, intensity, return numbers and classification, while formats 6 to 10 introduced in LAS 1.4 extend classification to 256 codes, allow up to 15 returns per pulse and add a near-infrared channel.

What Is LAZ?

LAZ is the output of LASzip, the compressor written by Martin Isenburg in 2007 to 2010 and released as open source in 2011. Rather than treating a file as a stream of bytes, it predicts each field from the values of previous points: coordinates follow the scan pattern, GPS time increases steadily, classification codes repeat across neighbouring points, so only the difference from the prediction has to be stored.

The format was published as an OGC Community Standard in September 2026, which formalizes what had long been common practice. LAZ 1.4 also adds support for LAS point formats 6 to 10 and splits each chunk into layers that hold separate fields, so a program can read coordinates without decompressing colour or waveform data.

How Much Space LAZ Saves

Because compression is driven by prediction of the next value, the result depends on the data. Regular airborne surveys with smooth terrain and sequential scan lines compress best; noisy intensity values, randomly ordered points and photogrammetric clouds with per-point colour compress less. The test below shows the important comparison: a general-purpose archiver applied to a LAS file cannot reach what a format-aware compressor achieves.

Synthetic airborne-style cloud of 5 million points, LAS 1.4 point format 6, written with laspy and LASzip. ZIP used default deflate settings. Real ratios depend on point density, attributes and point order.

There is a price for this, and it is processor time. In the same test, reading the LAS file took about 0.6 seconds and reading the LAZ file about 2.1 seconds, a difference that is invisible on a single tile and very visible when a job iterates over thousands of them. On slow storage or over a network the balance reverses, because transferring a quarter of the bytes saves more time than decompression costs.

Working with the Formats

In practice the two are used together. Data is delivered and archived as LAZ, then decompressed for the stages of processing that need repeated random access, and the results are compressed again. Most tools do this transparently: PDAL, laspy, LAStools, CloudCompare, QGIS and GDAL read LAZ directly, so an explicit conversion step is often unnecessary.

ArcGIS Pro is the exception worth knowing about. It reads .laz files, but only as part of a LAS dataset rather than as standalone layers, and it does not build a spatial index for them. Esri's own compressed format, .zlas, is treated as a first-class citizen instead, which is why Esri-centred workflows often convert incoming LAZ.

COPC and Cloud Workflows

Cloud Optimized Point Cloud is a valid LAZ 1.4 file whose chunks are arranged as an octree, with an index stored in a variable length record. A client can request the byte ranges for one part of the cloud at one level of detail and display it without downloading the rest, which is what makes point clouds usable directly from object storage.

Because a COPC file is still LAZ, any reader that supports LASzip can open it as an ordinary point cloud. This backward compatibility is the reason COPC spread quickly: publishing data in it costs nothing for existing users.

Common Mistakes

The most common misconception is that compression loses precision. It does not: decompressing a LAZ file returns the original point records byte for byte, and the accuracy of the data is determined by the scale and offset values in the header, not by compression.

A more practical mistake is keeping archives in LAS. Storage and backup for an uncompressed project can cost several times more than for the same data in LAZ, without any gain, since decompression takes seconds per tile when the data is actually needed.

The third is ignoring point order. Compression, display and analysis all rely on points that are spatially coherent, so a cloud rewritten in random order both compresses worse and draws more slowly. Reordering or tiling the data before compression usually pays for itself.

FAQs

Is LAZ lossless?

Yes. The point records are restored exactly, and the header and variable length records are stored uncompressed, so nothing about the survey is changed.

Can LAZ be used directly, without converting to LAS?

In most software, yes. PDAL, laspy, LAStools, CloudCompare, QGIS, GDAL and many viewers read it natively. Conversion is only needed for tools that expect uncompressed input.

How much slower is reading LAZ?

For local files, expect reading to take roughly two to four times longer, depending on the point format and the library. When the data comes from a network or object storage, LAZ is often faster overall because far fewer bytes are transferred.

What is the difference between LAZ and zLAS?

Both are lossless compressed versions of LAS. LAZ is an open format with an open-source implementation and near-universal support, while zLAS is an Esri format supported mainly inside the ArcGIS ecosystem.

Which format should be used for delivery?

LAZ, unless the contract specifies otherwise. It transfers faster, costs less to store, and the recipient can open it in almost any lidar software or convert it to LAS in one command.

Key Takeaways

LAS and LAZ are the same data in two states. LAS gives direct access to every point at the cost of size; LAZ trades processor time for a file several times smaller, without losing a single value. Because the transformation is reversible and cheap, the choice is a matter of stage rather than preference.

The usual arrangement is to store and deliver in LAZ, and decompress only for processing steps that genuinely benefit from uncompressed access. For data published on the web, COPC extends the same format with an internal index and makes partial reads possible without changing anything for existing users.