LAS vs LAZ: What Is the Difference in Point Cloud Data?

Point clouds can contain millions or even billions of individual three dimensional points.

That amount of information creates a practical problem.

How should all of those points be stored, transferred, archived, and delivered?

Two file formats appear constantly in professional point cloud workflows:

• LAS
• LAZ

They are closely related.

The simplest explanation is that LAS is a widely used point cloud file format, while LAZ is a compressed representation of LAS data.

That sounds straightforward, but understanding the difference becomes important when working with drone photogrammetry, LiDAR, surveying, GIS, construction documentation, and reality capture.

File size, compatibility, metadata, classification, transfer speed, and long term storage can all influence which format makes more sense.

If you need the underlying product first, start with what a point cloud is.

What is a LAS file?

LAS is a binary file format designed specifically for storing three dimensional point cloud data.

It was originally developed around airborne laser scanning workflows, but it has become widely used across the broader geospatial industry.

A LAS file can store much more than simple XYZ coordinates.

Depending on how the point cloud was produced and processed, individual points may also contain attributes such as:

• X coordinate
• Y coordinate
• Z coordinate
• Intensity
• Return information
• Classification
• RGB color
• GPS time
• Scan information
• Other attributes supported by the relevant LAS specification

This makes LAS much more useful than a generic text file containing coordinates.

It provides a structured way for geospatial software to understand both the position of each point and additional information associated with it.

Why point cloud files become so large

Point clouds are fundamentally data heavy.

Imagine a dataset containing 100 million points.

At minimum, each point needs to describe a position in three dimensional space.

Additional attributes increase the amount of information stored.

Now scale that to several hundred million points or more.

The result can quickly become a very large file.

High density LiDAR surveys, detailed drone photogrammetry projects, mobile scanning, terrestrial laser scanning, and large area mapping can all create substantial datasets.

Large LAS files can affect:

• Upload time
• Download time
• Cloud storage
• Local storage
• Archiving
• Backup time
• Data transfer
• Client delivery
• Processing performance

That is where LAZ becomes useful.

What is a LAZ file?

LAZ is a compressed form of LAS point cloud data.

Its purpose is to reduce storage requirements while preserving the underlying point cloud information in a format designed specifically for this type of data.

A useful analogy is the relationship between an uncompressed file and a compressed archive, although LAZ is specifically designed around LAS point cloud information.

Instead of storing the point cloud in its larger LAS representation, LAZ compresses the data so it requires less storage.

Software that supports LAZ can decompress the information when needed.

Does LAZ reduce point cloud quality?

In normal LAS to LAZ workflows, LAZ uses lossless compression.

That distinction matters.

Lossless compression means the data can be reconstructed without intentionally discarding the stored point information simply to reduce file size.

This is different from lossy compression used in some image, audio, and video formats where information may be permanently removed to achieve smaller files.

Converting an appropriate LAS dataset to LAZ is therefore not the same as simplifying a point cloud or deleting points.

Compression and point reduction are different operations.

Compression versus decimation

These two concepts should not be confused.

Compression reduces how efficiently the same information is stored.

Decimation reduces the amount of point data.

For example, a dense point cloud may be simplified from 100 million points to 20 million points.

That changes the dataset.

A LAZ compression workflow, by contrast, is intended to store the point cloud more efficiently without using point removal as the compression method.

This distinction is important when preparing professional deliverables.

A smaller file does not automatically mean data was removed.

You need to know whether the dataset was compressed, simplified, cropped, filtered, or otherwise processed.

What information can LAS and LAZ contain?

Both formats can contain structured point cloud information.

Depending on the dataset and LAS version, that information may include:

• Three dimensional coordinates
• Point classifications
• Intensity values
• Return numbers
• Number of returns
• RGB values
• GPS time
• Scanner or flight related information
• User defined information supported by the format

Not every point cloud contains all of these attributes.

For example, a photogrammetry generated point cloud may contain RGB color but may not contain the same type of return information associated with a LiDAR sensor.

The format defines ways information can be stored.

The capture system and processing workflow determine what information actually exists.

Point classification

One of the important features of LAS based workflows is point classification.

Points can be assigned classification values that describe what they represent.

Examples may include:

• Ground
• Vegetation
• Buildings
• Water
• Noise
• Other defined or custom classes

Classification can be extremely useful in terrain and mapping workflows.

A classified point cloud can allow software to separate ground points from other objects.

That can be particularly important when producing terrain models.

However, simply opening a LAS or LAZ file does not guarantee that the point cloud has been accurately classified.

Classification is part of processing.

The file format only provides a structure for storing that information.

LAS and LiDAR

LAS is strongly associated with LiDAR because the format was designed around point cloud data commonly produced by laser scanning systems.

LiDAR sensors can record information that differs from image based photogrammetry.

Depending on the sensor and workflow, LiDAR points may contain:

• Return number
• Number of returns
• Intensity
• Scan angle related information
• GPS time
• Classification
• Other sensor specific information

These attributes can be important for terrain mapping, vegetation analysis, asset extraction, and other geospatial workflows.

Surveying and mapping teams often depend on those attributes remaining intact when the file moves into GIS or engineering software.

LAS and drone photogrammetry

Drone photogrammetry can also produce point clouds that are exported as LAS or LAZ.

The points in this case are reconstructed from overlapping photographs rather than directly measured using laser pulses.

The resulting file can still contain XYZ coordinates and other attributes such as RGB color.

This means two LAS files can represent point clouds created using completely different capture technologies.

One may originate from LiDAR.

Another may originate from photogrammetry.

The file extension alone does not tell you how the point cloud was captured.

Project documentation should make that clear. Drone operators run into this as soon as processing writes the cloud.

LAS versus LAZ file size

The most obvious practical difference between LAS and LAZ is storage size.

LAZ normally requires significantly less storage than the equivalent uncompressed LAS data.

The exact reduction varies with the dataset.

Factors can include:

• Point attributes
• Point distribution
• Coordinate structure
• File version
• Compression implementation
• Dataset characteristics

Because of this variation, avoid assuming one universal compression percentage.

The important point is that LAZ exists specifically to make LAS point cloud storage and transfer more efficient.

Why smaller point cloud files matter

Large point clouds create problems beyond simply filling a hard drive.

Consider a mapping team delivering a project remotely.

A large LAS file may need to be:

• Uploaded to cloud storage
• Downloaded by the client
• Copied between workstations
• Backed up
• Archived
• Transferred to engineering teams
• Imported into downstream software

Every extra gigabyte affects that workflow.

Compressed LAZ files can make point cloud exchange significantly more practical when all required software supports the format.

Compatibility

Compatibility is one of the primary reasons LAS still matters.

LAS has been supported by geospatial software for many years.

LAZ is also widely supported, but compatibility should never be assumed blindly.

Some older software, specialized systems, import pipelines, or custom workflows may expect LAS.

A client may specifically request:

• LAS
• LAZ
• Another point cloud format
• A particular LAS version
• A particular classification structure
• A particular coordinate reference system

The correct delivery format should be determined by the receiving workflow.

Do not convert files merely because one extension appears more modern.

Should you deliver LAS or LAZ?

If the client explicitly requests a format, follow the specification.

If there is no required format, LAZ can be attractive because of its reduced storage and transfer requirements.

However, the most important questions are:

• Can the recipient's software open LAZ?
• Does their processing workflow require LAS?
• Do they need the original attributes?
• Do they require a specific LAS version?
• Will the data be archived long term?
• Will the dataset move between multiple organizations?
• Are there contractual file format requirements?

A technically efficient format is only useful if the intended users can work with it.

LAS versions matter

LAS has evolved over time.

Different versions of the specification support different point record structures and capabilities.

This can become important when moving data into older software.

A point cloud may technically be a LAS file but still use features or record formats unsupported by the recipient's application.

That means compatibility is not always as simple as checking the file extension.

For professional delivery, version requirements should be confirmed when the receiving system has strict specifications.

Coordinate reference systems

A point cloud needs spatial context.

LAS and LAZ files may contain geospatial reference information, but project teams should still document the coordinate reference system clearly.

The recipient may need to know:

• Horizontal coordinate reference system
• Vertical reference
• Units
• Datum
• Projection
• Geoid or elevation reference where applicable
• Transformation methodology where applicable

A point cloud can appear visually correct while being positioned incorrectly relative to another dataset if coordinate systems do not match.

This is especially important when combining point clouds with:

• CAD files
• GIS layers
• Design surfaces
• Orthomosaics
• Survey control
• Existing conditions data
• Other project captures

File delivery should make coordinate context obvious. Drone photogrammetry accuracy explained covers why a correctly stored file can still sit in the wrong place.

LAS and elevation models

Point clouds are often used as an intermediate or final source for generating elevation products.

Ground classified points can contribute to a Digital Terrain Model.

A broader visible surface point set may contribute to a Digital Surface Model.

The relationship is important:

LAS or LAZ can contain individual three dimensional points.

DSM and DTM products typically represent elevation through a raster or surface representation derived from spatial data.

They solve different problems.

A point cloud preserves detailed three dimensional observations.

An elevation model makes the surface easier to analyze as a continuous grid or derived terrain product.

For more detail, see the SpearAtlas guide explaining DSM, DTM, and DEM elevation models.

LAS versus PLY

PLY is another format frequently encountered in three dimensional workflows.

PLY can store point cloud geometry and other information such as color.

However, PLY is more common in general 3D graphics, reconstruction, and computer vision workflows.

LAS is built specifically around geospatial point cloud use cases.

That makes LAS and LAZ more appropriate for many professional GIS, LiDAR, mapping, and surveying workflows where geospatial attributes and standardized point records matter.

The correct choice still depends on what the downstream software expects.

LAS versus XYZ

Some point clouds are stored as plain text XYZ files.

Each row may contain values representing:

• X
• Y
• Z
• Potential additional attributes

Text based point data has the advantage of being relatively easy to inspect.

The disadvantage is efficiency.

Plain text coordinate files can become extremely large and may not preserve standardized point cloud attributes as elegantly as LAS.

LAS provides a structured binary format specifically designed for spatial point data.

LAS versus E57

E57 is another point cloud format commonly associated with terrestrial laser scanning and reality capture.

It can store three dimensional data along with additional information from scanning workflows.

LAS and E57 often appear in different parts of the reality capture ecosystem.

LAS is deeply established in geospatial and airborne mapping workflows.

E57 is common in terrestrial scanning and scan exchange.

There is overlap, but they should not automatically be treated as interchangeable.

The originating sensor, project requirements, software environment, and downstream workflow should determine the format.

Reality-capture teams often receive both, depending on whether the job started with airborne mapping or a terrestrial scanner.

LAS versus 3D mesh files

A LAS or LAZ file stores point data.

A mesh file such as OBJ or GLB represents surfaces made from connected geometry.

This is an important distinction.

Imagine scanning a building.

The point cloud contains many individual points describing the captured geometry.

A mesh creates surfaces between geometry so the structure can appear more continuous.

Meshes can be easier to visualize.

Point clouds can retain information useful for specialized spatial analysis.

Neither is universally better.

They are different representations of a three dimensional environment.

LAS versus Gaussian splats

Gaussian splatting represents a captured scene differently from a traditional point cloud.

Gaussian splats are heavily focused on reproducing visual appearance from changing viewpoints.

They can produce highly realistic interactive scenes.

LAS and LAZ, by contrast, are established geospatial point cloud formats designed around structured spatial point data.

A Gaussian splat can be excellent for visualization.

A LAS point cloud may be more appropriate for workflows that depend on standardized geospatial point data.

The correct representation depends on the task. Gaussian splatting for reality capture teams explains where splats fit without treating them as a replacement for survey point clouds.

Can you measure a LAS point cloud?

Point clouds can support measurement workflows when the dataset has appropriate scale, positioning, coordinate information, and accuracy.

Common measurements may include:

• Distances
• Elevations
• Height differences
• Cross sections
• Surface analysis
• Volumes
• Feature positions

However, measurement capability does not mean every point cloud is accurate enough for every decision.

The quality of a measurement depends on:

• Capture method
• Sensor quality
• Flight or scanning geometry
• Control
• Positioning
• Processing
• Coordinate systems
• Point density
• Surface quality
• Verification
• Intended use

Never judge measurement reliability from the file extension alone.

Point density

Point density describes how closely points are distributed throughout the dataset.

A denser point cloud may preserve more surface detail.

That does not automatically mean it is more accurate.

A dense but poorly positioned reconstruction can still contain error.

Likewise, excessive density can create enormous files without materially improving the final use case.

Capture and processing should be designed around the required result.

Cropping point clouds

Large point clouds may include data outside the actual project area.

Cropping can reduce unnecessary information and make datasets easier to manage.

This is different from compression.

Cropping intentionally removes points outside a selected region.

LAZ compression stores the remaining point data more efficiently.

These operations solve different problems and should be documented appropriately when relevant.

Splitting large point clouds

Very large datasets may be divided into multiple tiles.

Tiling can make point cloud processing and visualization easier because software does not always need to load the entire project simultaneously.

A tiled project may therefore contain multiple LAS or LAZ files representing different portions of the same mapped area.

The delivery package should preserve a clear naming and organization system so recipients understand how those tiles relate to one another.

COPC and cloud optimized point clouds

Modern geospatial workflows increasingly need to access very large point clouds without downloading an entire dataset first.

Cloud Optimized Point Cloud structures are designed around more efficient access to spatial subsets of large point datasets.

COPC commonly uses LAZ based storage with a structure intended to support efficient spatial querying.

This is especially useful for browser based and cloud geospatial applications.

Traditional LAS and LAZ files remain important, but cloud optimized structures demonstrate how point cloud delivery is evolving beyond simple file downloads.

Do not treat COPC as merely another filename extension without understanding the structure and software support required.

Point clouds in browser based workflows

Traditionally, opening a large point cloud required specialized desktop software.

That remains important for many professional workflows.

Browser based viewing creates another option.

A client or project stakeholder may want to inspect the spatial data without installing the same software used by the mapping professional.

This creates two separate requirements:

• Preserve the native point cloud.
• Make the project accessible to the people who need to review it.

These requirements are compatible.

The native LAS or LAZ file can remain available for technical users while a browser based viewer provides a more accessible way to explore the project. How to share mapping deliverables with a client covers that last mile without replacing the specialist file.

Delivering point clouds to clients

Sending a point cloud should involve more than attaching a large file.

A useful point cloud delivery should answer:

• What does this file contain?
• How was it captured?
• When was it captured?
• What coordinate system does it use?
• What units does it use?
• Was it classified?
• What processing was performed?
• What accuracy information is available?
• What software can open it?
• Are other deliverables part of the same project?

These questions become especially important when the client receives multiple products from one mapping mission.

A typical point cloud delivery package

Depending on the project, a point cloud delivery could include:

• LAS or LAZ point cloud
• Orthomosaic
• DSM
• DTM where required
• 3D model
• PDF report
• Control information
• Checkpoint results
• Coordinate system documentation
• Source photographs
• Supporting files

Not every project requires all of these products.

The package should reflect what the project was designed to accomplish. Drone mapping deliverables explained covers how those files relate to one another.

Construction teams often need the native cloud for specialists and a viewable project for everyone else.

Naming LAS and LAZ files

Clear file naming becomes increasingly important when projects contain multiple point clouds.

Instead of:

cloud.laz

A structured naming system might communicate:

• Project name
• Capture date
• Point cloud type
• Classification status
• Coordinate system when appropriate
• Tile identifier where applicable
• Version

For example, a project may distinguish between:

• Full point cloud
• Ground classified point cloud
• Individual tiles
• Filtered point cloud
• Updated processing version

The exact convention can vary.

Consistency is the important part.

Archiving point cloud data

Point clouds are often valuable long after the initial project is complete.

Construction records, existing conditions, land mapping, asset documentation, and reality capture projects may all become useful historical references.

Large uncompressed datasets make long term storage expensive.

LAZ can help reduce that burden while preserving structured point cloud information.

However, a good archive should include more than the point cloud itself.

It should preserve enough project context to understand the data later.

That may include:

• Capture date
• Coordinate reference system
• Processing information
• Control data
• Reports
• Related imagery
• Project notes
• Deliverable descriptions

Without that context, a technically valid point cloud can become difficult to interpret years later.

LAS and LAZ comparison

The practical difference can be summarized simply.

The important distinction is not data quality.

The primary distinction is how the information is stored.

Which format should you use?

Use the format that fits the complete workflow.

Choose LAS when:

• The client specifically requires LAS.
• The receiving application does not support LAZ.
• A legacy workflow expects uncompressed LAS.
• A contract or project specification requires it.

Choose LAZ when:

• Smaller storage is valuable.
• The dataset must be transferred frequently.
• The client software supports LAZ.
• Cloud storage or archival efficiency matters.
• You want to preserve the structured point cloud while reducing transfer size.

When uncertain, confirm compatibility with the recipient before final delivery.

The file format is only one part of the point cloud

A point cloud file extension cannot tell you whether the data is appropriate for a particular professional decision.

Two LAZ files can differ dramatically.

One may contain a high quality LiDAR survey tied to control and independently verified.

Another may contain an approximate photogrammetry reconstruction intended primarily for visualization.

Both can still use LAZ.

Understanding the dataset requires more context:

• Capture method
• Coordinate system
• Accuracy
• Point attributes
• Classification
• Processing
• Project purpose
• Verification

The format organizes the information.

The project methodology determines what that information means.

Professional point cloud delivery needs context

LAS and LAZ solve an important technical problem.

They provide standardized ways to preserve and exchange large point cloud datasets.

LAZ makes those datasets easier to store and transfer.

But professional delivery involves more than choosing an extension.

The recipient needs to understand how the point cloud relates to the orthomosaic, elevation models, 3D models, reports, photographs, and other files produced during the same mapping mission.

Keeping that information connected creates a much stronger project record.

The goal is not simply to send a point cloud.

The goal is to deliver spatial data that another person can identify, understand, access, and use correctly.