LAS vs LAZ: What’s the Difference in LiDAR Files?

Summary

LAS vs LAZ is mainly the difference between an uncompressed LAS file and a losslessly compressed LAZ file within the same LiDAR point cloud format family. A LAS file is an open exchange format for point cloud data, while a LAZ file preserves the same point-field meaning but stores the point data in compressed form. [1] [4]

In practice, you encounter both in aerial lidar, drone mapping, corridor survey, and reality-capture deliverables. Lossless compression is not thinning, decimation, or resampling, so LAZ does not inherently reduce point quality. The bigger risk is workflow: software may misread or drop CRS metadata, miss Extra Bytes schemas, or rewrite scale and offset values during conversion if you do not check them explicitly. [4] [2] [3]

LAS vs LAZ: The core difference (and the “compressed LAS” answer)

A LAS file is the uncompressed binary container traditionally used to exchange LiDAR point clouds between tools. In the format definition, the file contains a Public Header Block, optional VLRs, point data records, and optional EVLRs, all in little-endian order. VLR payloads are limited to 65,535 bytes, which is one reason larger metadata blocks or later-added metadata may end up in EVLRs instead. [2]

A LAZ file keeps that overall LAS-oriented structure, but applies a standardized lossless compression to the point data block. The current OGC LAZ 1.4 Community Standard says LAZ 1.4 is based on LAS 1.4 and does not change the meaning of the uncompressed LAS point fields. In other words, LAZ changes storage, not the semantic meaning of coordinates, classifications, returns, or other point attributes. [4]

So, is LAZ just a compressed LAS? Yes, in the sense that the point-field meaning is preserved. No, in the sense that it is not a generic ZIP wrapper around a .las file. LAZ changes container signaling by adding 128 to the LAS point data record format, adds a LAZ-specific VLR that identifies the file and describes the compression, and replaces the original point-data block with a compressed one. Metadata still has to be checked after opening or conversion. [4]

For most users, the practical difference is workflow rather than analytic quality. LAS is simpler for software or scripts that expect uncompressed records, while LAZ reduces storage and transfer cost when the receiving software can decode it correctly and preserve the metadata you care about. [4] [2]

A clean timeline: LAS as exchange format → LAS 1.4 baseline → LAZ 1.4 standardization

LAS exists to let different hardware and software tools exchange point cloud data in a common format. For interoperability discussions today, LAS 1.4 is the key baseline because the OGC LAS 1.4 Community Standard was published on March 1, 2018, as document 17-030r1. OGC also warns that this Community Standard is fixed in content even though ASPRS, the originating body, may continue updating the specification separately. That distinction matters because many real-world archives and procurement profiles still target LAS 1.4 conventions even though newer ASPRS revisions now exist. [1] [3]

LAS 1.4 itself does not include compression, which is why LAZ needed separate standardization instead of being treated as a feature inside the LAS 1.4 document. The OGC LAZ 1.4 Community Standard was approved on April 23, 2026, and published on June 30, 2026, as document 24-070r1. That formalizes LAZ as the lossless, LAS-aware compression format widely used for storage and delivery where large point clouds need to move efficiently between organizations. [3] [4]

What a LAS file can store (and what it cannot)

A LAS file stores point records plus point attributes, but the exact attribute set depends on the chosen point data record format, or PDRF. In LAS 1.4, formats 0 through 10 are defined, all point records in a single file must use the same PDRF, and formats 6 through 10 are the preferred modern set. That means two LAS files can both be valid while carrying different combinations of GPS time, color, NIR, or waveform-related fields. [3]

Practically, the file is organized as header first, then optional VLRs, then the point records, then optional EVLRs. The header tells software how many points exist, what PDRF is in use, and how to interpret scaled coordinates. VLRs are where much of the metadata lives, but each VLR is limited to 65,535 bytes. EVLRs allow larger payloads and can be appended to the end of the file, which is useful when metadata such as projection information needs to be added without rewriting the entire point-data block. [2]

LAS and LAZ store point clouds, not finished meshes, DEMs, or STL-style geometry. Those can be derived from the points later, but they are different data products. Common point attributes you may see include the following. [1] [2] [3]

• X, Y, and Z coordinates, stored from integer point values plus scale and offset. [2]
• Intensity, usually representing pulse return magnitude in a normalized integer field. [2]
• Return number and number of returns, which describe multi-return behavior for a pulse. [2] [3]
• Classification and related flags, whose richness depends on the PDRF generation in use. [3]
• GPS time, which is mandatory in PDRF 6 and the related 6–10 family design. [3]
• RGB and, where supported, NIR values in the color-capable point formats. [3]
• Waveform-related fields, but only in some point formats rather than in every LAS file. [3]
• Extra Bytes or other custom dimensions, when a producer appends additional per-point values beyond the standard fields. [3]

What a LAZ file changes (container-level only)

At the storage level, LAZ replaces uncompressed point data with losslessly compressed point data. That means the values come back unchanged after decoding, so LAZ is not a thinning, decimation, or resampling step. LAZ also stores point data in chunks, and each chunk can be decompressed independently, which is why random access is possible at chunk granularity instead of requiring the whole file to be unpacked first. [4]

At the binary container level, several things change even though the point meaning does not. LAZ adds 128 to the Point Data Record Format value, so values 128 through 138 correspond to LAS formats 0 through 10. It adds a required LAZ special VLR that identifies the file and describes the compression, and it places a compressed data block where LAS would have stored plain point records. Optionally, a chunk-table pointer can appear at the end of the file. That is why LAZ should be understood as LAS-aware compression, not as “LAS inside ZIP.” [4]

Metadata & CRS: where it lives, what can go wrong

One of the easiest mistakes in LAS or LAZ handling is to confuse stored coordinates with coordinate reference system metadata. The stored X, Y, and Z values are integer record values interpreted through scale and offset, while the CRS is separate metadata carried in VLRs or EVLRs. A file can therefore have numerically valid coordinates and still have missing, ambiguous, or incorrect spatial reference metadata. [2]

In LAS 1.4, CRS metadata normally lives under the LASF_Projection user ID. The WKT-based records are Record ID 2111 for Math Transform WKT and 2112 for Coordinate System WKT. The GeoTIFF-style records are Record IDs 34735, 34736, and 34737 for the GeoKeyDirectory, GeoDoubleParams, and GeoAsciiParams structures. Real files may contain WKT, GeoTIFF, both, or neither, and software can misread or omit them during translation. That is why safe workflow means inspecting CRS metadata before analysis, reprojection, tiling, or export, rather than assuming the map view “looks right.” [3]

There is also a version caveat. ASPRS LAS 1.5 Revision 00 was released on August 26, 2025, and its major changes include expanded WKT CRS support and removal of GeoTIFF CRS encoding. LAS 1.5 also makes PDRFs 0 through 5 invalid for LAS 1.5 files. Even so, most interchange discussions still need to stay centered on LAS 1.4 and LAZ 1.4 because that is where many archives, deliverables, and toolchains operate. Scale and offset control storage precision, not survey accuracy. Changing them can alter how coordinates are quantized in the file without saying anything by itself about how accurate the survey was in the field. [6] [2]

Point formats (PDRF) vs Extra Bytes (custom dimensions)

PDRF-defined fields are the fields guaranteed by the selected point format. In LAS 1.4, all points in one file must share a single PDRF, and the preferred modern formats are 6 through 10. PDRF 6 is the core 30-byte structure shared by 6 through 10, adding support such as up to 15 returns, 256 classes, higher-precision 16-bit scan angle storage instead of 8-bit, and mandatory GPS time. If a dimension is part of the chosen PDRF, conforming software should know where that field belongs. [3]

Extra Bytes are different. They are custom per-point dimensions appended after the standard PDRF fields, and their meaning is described by the Extra Bytes VLR under user ID LASF_Spec, Record ID 4. This is powerful, but portability depends on that schema surviving the workflow and on the next tool honoring it. PDAL’s writer documentation makes the preservation issue concrete: forwarding header values, scale, offset, and VLR content is explicit behavior, not something you should assume happens automatically in every conversion. [3] [9]

A practical example is that RGB may be PDRF-defined in a color-capable point format, while a custom dimension such as amplitude or echo width may be stored as Extra Bytes instead. If the schema for those Extra Bytes is dropped or rebuilt incorrectly, the points may still open, but the custom dimension can become meaningless to downstream software. [3] [9]

Waveform data: why some LAS/LAZ files don’t open everywhere

Waveform-capable files are a special case. In LAS 1.4, PDRFs 4, 5, 9, and 10 add waveform packet fields. That does not mean every file in those formats contains identical waveform handling in practice, but it does mean readers need more than the usual XYZ and attribute logic. A file that is otherwise valid may fail in a tool simply because that tool does not implement those waveform-related point formats. [3]

PDAL’s current readers.las documentation is explicit that it does not support waveform point formats 4, 5, 9, and 10. LAZ 1.4 adds another constraint: internally stored waveform data in an EVLR is not supported, so waveform packets must use an auxiliary file such as .WDP, and the standard notes that internal waveform storage is also deprecated in LAS 1.4. When a waveform file does not open cleanly, the first suspicion should be support limits, not automatic corruption. [7] [4]

How to open LAS/LAZ files (viewing + conversion without losing metadata)

Opening LAS or LAZ correctly depends on two things: whether the software can decode the file, and whether it interprets the metadata the way you expect. LAZ requires a LAZ-aware reader, not a generic decompression utility. Support also changes over time, so it is worth checking the documentation for the exact version or build you are using, especially if the file uses modern PDRFs, waveform fields, or custom dimensions. [4] [7] [18]

QGIS 3.44 is a good example of behavior that matters in practice. Its point-cloud documentation says that when the source is LAS or LAZ, QGIS converts it to EPT on first load and creates an ept_... subfolder beside the source data. That means first open can take time and consume extra disk space, while later opens are faster because QGIS reuses the cached EPT structure. [10]

Other tools have different boundaries. ArcGIS Pro’s current Create LAS Dataset documentation says LAS datasets can reference .las, .zlas, and .laz files, and it warns that missing or incorrect spatial reference information can leave files with unknown spatial reference. CloudCompare should be treated as build-dependent, because the official build documentation says LAS/LAZ support requires LASzip through the qLASIO path. Autodesk ReCap’s supported-formats page lists LAS import and RCP/RCS export, but does not list LAZ, so an upstream conversion step may be necessary in some CAD/BIM workflows. [11] [18] [12]

A safe conversion workflow is simple but strict. [2] [3] [9]

1. Inspect the header and CRS metadata first, including whether WKT or GeoTIFF projection VLRs are present. [3]
2. Confirm the point format and whether Extra Bytes exist, because custom dimensions are only portable when the schema survives. [3] [9]
3. Use LAZ-capable tools and documentation-qualified workflows, such as QGIS 3.44, PDAL’s LAS/LAZ stages, ArcGIS Pro’s LAS dataset tools, or a CloudCompare build compiled with LASzip support. [10] [7] [11] [18]
4. When converting, explicitly preserve scale, offset, compatible point format choices, and the VLR/EVLR and Extra Bytes schema. PDAL’s writer documentation shows that forwarding behavior is configurable rather than automatic, so “convert” does not guarantee metadata preservation. [2] [9]
5. Treat DEM, mesh, and CAD exports as derived products rather than as simply “opening” a LAS or LAZ file. A point cloud is still a point cloud until you intentionally derive something else from it. [1]

File size & performance: what the sources actually say

Published size and speed figures should be read as examples, not promises. In Martin Isenburg’s 2013 LASzip paper, the reported compressed size is 7 to 25 percent of the original file size, with encoding and decoding around 1 to 3 million points per second and random-access support at a default granularity of 50,000 points. PDAL’s workshop documentation gives a different rule of thumb, saying typical LASzip compression is 5:1 to 8:1 depending on the LiDAR. Esri’s ArcGIS Pro documentation offers another dataset-oriented figure, saying compressed files typically use approximately 30 percent of the storage size of uncompressed files. Those numbers are best kept separate rather than averaged into one slogan. [16] [8] [11]

Why do the ratios vary so much? Because compression depends on the data itself: attribute mix, point ordering, presence of color or waveform-related content, coordinate precision choices, noise, and implementation details all matter. LAZ is reliably lossless, but no credible source supports one universal “always shrinks by X percent” claim across all point clouds. [4] [8] [16]

LAS/LAZ vs COPC (and quick notes on EPT and ZLAS)

COPC is not a different raw point meaning than LAZ. The COPC specification defines a COPC file as a LAZ 1.4 file whose point data are organized in a clustered octree. The point attributes still come from LAS/LAZ conventions, but the spatial organization is optimized for streaming and partial access, which is why COPC often feels different in web, cloud, or very large-dataset workflows. [17]

The limitation is that COPC is not “any LAZ file.” The specification requires only LAS PDRFs 6, 7, or 8, so a generic .laz file and a .copc.laz file should not be treated as interchangeable labels. EPT is best understood here as an indexed storage and streaming structure that also appears in QGIS’s first-load workflow for LAS or LAZ. ZLAS is an Esri ecosystem clarifier: ArcGIS Pro documentation discusses .zlas alongside .las and .laz, which is enough reason not to confuse it with LAZ even though both are compressed point-cloud containers. [17] [10] [11]

Current standards & real-world profiles

The standards snapshot on September 21, 2026, is straightforward. OGC LAS 1.4 was published on March 1, 2018. OGC LAZ 1.4 was approved on April 23, 2026, and published on June 30, 2026. Separately, ASPRS LAS 1.5 Revision 00 was released on August 26, 2025, with notable changes such as dropping PDRFs 0 through 5 for LAS 1.5 and expanding WKT-based CRS support. That newer ASPRS status is real, but it should be treated as a bounded caveat rather than a reason to reinterpret older LAS 1.4 and LAZ 1.4 holdings. [3] [4] [6] [2]

For a concrete market example, the U.S. Geological Survey’s Lidar Base Specification 2025 rev. A, released on June 10, 2025, requires point deliverables in LAS 1.4-R15 using PDRFs 6 through 10 and requires delivery in LAZ 1.4. It also says LAZ 1.4 files compressed in compatibility mode shall not be used. That is a U.S. procurement example, not a universal global rule, but it is a strong indicator of current field reality for major public-sector deliverables. The compatibility-mode restriction matters because that legacy mode stores PDRFs 6 through 10 as 0 through 5 plus Extra Bytes under older LAZ 1.2 or 1.3 headers rather than as normal LAZ 1.4. [15] [14] [13] [4]

LAS vs LAZ: which should you choose?

For most modern exchange and delivery workflows, LAS vs LAZ is not a question of quality loss. It is a question of compatibility, storage, and metadata discipline. Choose LAZ when your toolchain supports it and storage or transfer efficiency matters. Choose LAS when a downstream tool, script, or vendor handoff specifically requires uncompressed records. Consider COPC when you need LAZ-compatible content plus better partial-access behavior for large or remote datasets. In all cases, preserve CRS metadata, PDRF fidelity, scale and offset, and any Extra Bytes schema. Also remember that a point cloud is not the same thing as a mesh or DEM, even if you plan to derive those later. [4] [17] [13]

• Choose LAZ when you want smaller deliverables, faster transfer, and the receiving software is confirmed to be LAZ-capable. [4] [13]
• Choose LAS when a required tool or exchange partner expects uncompressed LAS, or when you need the simplest possible debugging path for metadata inspection. [1] [2]
• Consider COPC when you need LAZ 1.4 semantics plus octree-style organization for cloud or partial-access workflows. [17]
• Never do this: export to plain XYZ or another stripped format and assume classifications, CRS, GPS time, color, or Extra Bytes will survive intact. Use those only when you knowingly accept attribute loss. [3] [9]

FAQ

LAS vs LAZ: what is the difference?

LAS is the uncompressed exchange container for point cloud data, while LAZ is the losslessly compressed, LAS-aware variant. The point attributes mean the same thing after decoding, but LAZ changes the storage layer by adding LAZ signaling and a compression VLR, and by replacing plain point records with a compressed data block. [2] [4]

Is LAZ just a compressed LAS?

Yes, if you mean that LAZ preserves the same point-field meaning as LAS. No, if you mean “a LAS file wrapped in ZIP.” LAZ has its own container-level signaling, including PDRF values 128 through 138, a LAZ special VLR, chunked compressed point storage, and optional chunk-table mechanics for random access. [4]

Does LAZ reduce point cloud quality?

Not by itself. LAZ is lossless, so the decoded point values are the same values that were encoded. What can go wrong is not the compression itself, but the surrounding workflow: a bad conversion can change scale and offset handling, drop CRS metadata, or lose Extra Bytes definitions. [4] [2] [3]

Where is the coordinate system stored in a LAS/LAZ file?

In LAS 1.4-era practice, the CRS is stored in VLRs or EVLRs, not in the XYZ integers themselves. The main LASF_Projection records are 2111 and 2112 for WKT content, and 34735, 34736, and 34737 for GeoTIFF-style CRS metadata. That is why checking the header alone is not enough if you skip the metadata records. [3]

What’s the difference between PDRF fields and Extra Bytes?

PDRF fields are the standard fields guaranteed by the chosen point format for every point in the file. Extra Bytes are custom appended dimensions described by the LASF_Spec Record ID 4 schema. If the Extra Bytes VLR is missing, ignored, or rebuilt incorrectly, the points may still load but the custom dimensions may no longer be interpretable. [3] [9]

Why won’t some tools open my LAS/LAZ waveform data?

Because waveform support is more specialized than ordinary point support. Waveform-related fields appear in PDRFs 4, 5, 9, and 10, and some software does not implement them. PDAL’s readers.las explicitly does not support those waveform formats, and LAZ 1.4 does not allow internally stored waveform EVLR data, requiring an auxiliary .WDP file instead. [3] [7] [4]

How do I convert LAZ to LAS without losing metadata?

Start by inspecting CRS metadata, PDRF, scale and offset, and whether Extra Bytes exist. Then use a tool that lets you preserve or forward header values and relevant VLR content explicitly. After conversion, re-check the output rather than assuming the metadata came across automatically, because writer behavior is tool-specific. [2] [3] [9]

Sources

1. ASPRS LAS 1.5 Intro (Purpose + status) — https://lasformat.org/latest/01_intro.html
2. ASPRS LAS 1.5 Format Definition (structure, VLR/EVLR, X/Y/Z storage, scale/offset) — https://lasformat.org/latest/02.00_definition.html
3. OGC LAS 1.4 Community Standard (17-030r1, published 2018-03-01) — https://docs.ogc.org/cs/17-030r1/17-030r1.pdf
4. OGC LAZ 1.4 Community Standard (24-070r1, published 2026-06-30) — https://docs.ogc.org/cs/24-070r1/24-070r1.pdf
5. OGC LAS standards listing page (LAS + LAZ doc numbers discoverability) — https://www.ogc.org/standards/las/
6. ASPRSorg/LAS GitHub Releases (LAS 1.5 R00 major changes; LAS 1.4 R16 status) — https://github.com/ASPRSorg/LAS/releases
7. PDAL readers.las (LAZ reading + waveform limitation) — https://pdal.org/en/latest/stages/readers.las.html
8. PDAL compression workshop note (typical 5:1–8:1) — https://pdal.org/en/latest/workshop/introduction/compression.html
9. PDAL writers.las (forwarding header/VLR notes; extra dims/Extra Bytes behavior) — https://pdal.org/en/2.6.3/stages/writers.las.html
10. QGIS 3.44 point clouds manual (LAS/LAZ → EPT first-load conversion; COPC mention via VPC context) — https://docs.qgis.org/3.44/en/docs/user_manual/working_with_point_clouds/point_clouds.html
11. Esri ArcGIS Pro Create LAS Dataset tool (30% storage note) — https://doc.esri.com/en/arcgis-pro/latest/tool-reference/data-management/create-las-dataset.html
12. Autodesk ReCap supported file formats (LAS import; RCP/RCS export) — https://help.autodesk.com/view/RECAP/ENU/?contextId=supported_file_formats
13. USGS Lidar Base Specification 2025 rev. A — Deliverables (LAZ 1.4; no compatibility mode) — https://www.usgs.gov/ngp-standards-and-specifications/lidar-base-specification-deliverables
14. USGS Lidar Base Specification 2025 rev. A — Data Processing/Handling (LAS 1.4-R15; PDRF 6–10) — https://www.usgs.gov/ngp-standards-and-specifications/lidar-base-specification-data-processing-and-handling-requirements
15. USGS LBS Online overview (release date June 10, 2025) — https://www.usgs.gov/ngp-standards-and-specifications/lidar-base-specification-online
16. Isenburg LASzip paper PDF (compression examples + performance) — https://www.cs.unc.edu/~isenburg/lastools/download/laszip.pdf
17. COPC 1.0 specification site (COPC = LAZ 1.4 + octree; PDRF constraints) — https://copc.io/
18. CloudCompare build documentation (LAS/LAZ support depends on LASzip / plugin) — https://github.com/CloudCompare/CloudCompare/blob/master/BUILD.md
19. Library of Congress FDD: LAS 1.4 description (plain-language + preservation context) — https://www.loc.gov/preservation/digital/formats/fdd/fdd000418.shtml
20. OGC announcement (context-only, not for hard dates) — https://www.ogc.org/announcement/ogc-announces-publication-of-the-laz-1-4-community-standard/