LAS File Documentation

---

Technical details

Feature	Value
Full name	LASer file (LiDAR point cloud)
File extension	.las
MIME type	application/octet-stream
Format type	Binary point-cloud interchange format
Developer	ASPRS (American Society for Photogrammetry and Remote Sensing)
Introduced	2003 (LAS 1.0)
Current version	LAS 1.4 — R14, published 2011–2019
Standard / spec	ASPRS LAS Specification 1.4
Open standard	Yes — public, vendor-neutral
Byte order	Little-endian
Magic number	4C 41 53 46 ("LASF") at offset 0
Top-level structure	Public Header Block, VLRs, Point Data Records, EVLRs
Point data record formats	PDRF 0–10 (0–5 legacy; 6–10 preferred)
Per-point attributes	X/Y/Z, intensity, return number, classification, scan angle, GPS time, RGB, NIR
Coordinate storage	32-bit integers scaled by header scale + offset
CRS metadata	OGC WKT (LAS 1.4) or GeoTIFF keys in VLRs
Compressed twin	.laz (lossless, ~10–20% of the size)
Related extensions	.laz, .copc.laz, .e57, .xyz, .ply, .pts
Category	Data / GIS point cloud
Specification URL	asprs.org/wp-content/uploads/2019/07/LAS_1_4_r15.pdf

What is a LAS file?

LAS is short for LASer, the public binary file format for exchanging three-dimensional point-cloud data captured by LiDAR (light detection and ranging) sensors. It is maintained by the American Society for Photogrammetry and Remote Sensing (ASPRS), which published version 1.0 in 2003 and the current version 1.4 in 2011. The format exists so LiDAR data from different scanners and software can move between systems without a proprietary wrapper. A single .las file stores a large set of measured returns, each one a point with X, Y and Z coordinates plus attributes such as intensity, return number, scan angle, GPS time and an ASPRS classification code (ground, building, low/medium/high vegetation, water, and so on).

A LAS file is data, not a picture. There is no rendered image inside it; you need point-cloud software to visualise the millions of points it holds. Because the points are stored uncompressed, LAS files are large, routinely hundreds of megabytes to several gigabytes, which is why the losslessly compressed twin LAZ is so common. Everything below is about how the binary file is laid out: the header, the variable-length records, and the fixed-width point records that make up the bulk of the file. The specification is published by ASPRS.

The four-part file layout

A LAS file is a strict sequence of four regions, read in order. Each region's position is not fixed by a template; instead, byte offsets recorded in the Public Header Block tell a reader exactly where the next region begins. That indirection is what lets the format grow between versions without breaking older parsers.

+---------------------------+  offset 0
| Public Header Block       |  fixed-size header (375 bytes in LAS 1.4)
+---------------------------+  Header Size / Offset to point data
| Variable Length Records   |  CRS (WKT/GeoTIFF), extra-bytes descriptors, metadata
+---------------------------+  "Offset to point data"
| Point Data Records        |  the points themselves, one fixed-width record each
+---------------------------+  "Start of first EVLR"
| Extended VLRs (EVLRs)     |  large records placed AFTER the points (LAS 1.4)
+---------------------------+  end of file

The Public Header Block always starts at offset 0. Variable Length Records (VLRs) follow immediately after it. The Point Data Records begin at the byte named by the header's Offset to point data field, so a reader never guesses where the points start — it jumps straight there. Extended VLRs, new in LAS 1.4, sit after the points because they can be very large (a full waveform description, for example) and placing them last keeps the point block contiguous.

The Public Header Block, field by field

The Public Header Block opens with the 4-byte signature LASF (hex 4C 41 53 46) and then packs the file-level metadata a reader needs before it can interpret a single point. All integers are little-endian. The block is a fixed 375 bytes in LAS 1.4 (it grew from 227 bytes in LAS 1.0 as fields were added).

offset  size  field
0       4     File Signature = "LASF"
4       2     File Source ID
6       2     Global Encoding (bit flags: GPS time type, WKT, etc.)
24      1     Version Major        (=1)
25      1     Version Minor        (0,1,2,3,4)
26      32    System Identifier
58      32    Generating Software
94      2     File Creation Day of Year
96      2     File Creation Year
98      2     Header Size          (375 for 1.4)
100     4     Offset to point data
104     4     Number of VLRs
108     1     Point Data Record Format   (0-10)
109     2     Point Data Record Length   (bytes per point)
111     4     Legacy Number of point records
115     20    Legacy points-by-return[5]
131     8     X scale factor  (double)
139     8     Y scale factor
147     8     Z scale factor
155     8     X offset
163     8     Y offset
171     8     Z offset
179     48    Max/Min X, Y, Z bounds (6 doubles)
...           (1.4 adds Start of Waveform / EVLR, and
              15 64-bit points-by-return entries)

Two field groups do the heavy lifting. Point Data Record Format and Point Data Record Length tell the reader which point layout is used and how many bytes each point occupies, so it can stride through the point block without parsing every field. The scale and offset doubles are how LAS stores real-world coordinates in compact integers, explained next. The header also carries the bounding box (min/max X, Y, Z), the point count, and, in LAS 1.4, 64-bit point counts that lift the old 32-bit ceiling of roughly 4.29 billion points.

Scaled-integer coordinates

Point coordinates are not stored as floating-point numbers. Each point holds X, Y and Z as 32-bit signed integers, and the true coordinate is recovered with the header's scale and offset: real_X = X_int × X_scale + X_offset. A scale of 0.001 with an offset near the survey origin, for example, encodes millimetre precision while keeping each coordinate to four bytes. This is a deliberate trade: integers compress better and store a known, uniform precision, and the single scale/offset pair in the header applies to every point in the file.

Variable Length Records and the coordinate system

Between the header and the points sit the Variable Length Records. Each VLR has its own small header — a reserved field, a 16-byte User ID, a 2-byte Record ID, a 2-byte length, and a 32-byte description — followed by its payload. The count of VLRs is in the Public Header Block, so a reader knows how many to walk before reaching the point data.

The most important VLR describes the coordinate reference system. LAS 1.4 records the CRS as OGC Well-Known Text (WKT), signalled by a bit in the header's Global Encoding field; earlier versions used GeoTIFF keys carried in VLRs instead. Without this record, the raw X/Y/Z numbers are just measurements with no place on Earth. Other VLRs define extra bytes (extra per-point attributes beyond the standard set, each described by an Extra Bytes VLR so a reader knows the name and data type), classification lookup tables, and vendor metadata. Extended VLRs (EVLRs) use a 64-bit length field so they can exceed the 65,535-byte cap of a classic VLR, which is why they live after the point block.

Point Data Record Formats 0 through 10

The heart of a LAS file is the Point Data Records, a tightly packed array of fixed-width structures. Which structure is in use is set once, in the header's Point Data Record Format (PDRF) byte. LAS 1.4 defines eleven formats, 0 through 10. Formats 0–5 are the older ("legacy") layouts carried over from earlier versions; formats 6–10 are the preferred LAS 1.4 layouts, which widen several fields and add support for more returns per pulse.

PDRF	Adds over the base
0	Base: X, Y, Z, intensity, return info, classification, scan angle, GPS-less
1	Base + GPS time
2	Base + RGB colour
3	Base + GPS time + RGB
4	PDRF 1 + wave-packet (full-waveform) fields
5	PDRF 3 + wave-packet fields
6	New 1.4 base: GPS time, wider return/classification fields
7	PDRF 6 + RGB
8	PDRF 7 + near-infrared (NIR)
9	PDRF 6 + wave-packet fields
10	PDRF 8 + wave-packet fields

A format-0 point is 20 bytes: three 4-bytes integers for X/Y/Z (12 bytes), a 2-byte intensity, one byte packing the return number, number of returns, scan-direction flag and edge-of-flight-line flag, a classification byte, a scan-angle byte, a user-data byte, and a 2-byte point source ID. The legacy layout squeezes return number and number of returns into 3 bits each, capping a pulse at 5 returns. The 1.4 formats (6–10) spend an extra byte to give 4 bits each, raising the ceiling to 15 returns, and widen classification to a full byte so it can hold the ASPRS class codes beyond 31. Adding GPS time makes the record 8 bytes larger; adding RGB adds three 2-byte channels; NIR adds one more. The header's Point Data Record Length reflects whatever total the chosen format produces, and a reader multiplies it by the point count to know exactly how many bytes the point block spans.

Classification codes

The classification byte assigns each point to a category using ASPRS standard codes. A handful are fixed by the specification: 0 = never classified, 1 = unclassified, 2 = ground, 3–5 = low/medium/high vegetation, 6 = building, 7 = low point (noise), 9 = water, 11 = road surface. Codes are how software colours a cloud by feature or extracts just the ground returns to build a terrain model, without re-processing the geometry.

LAS versus LAZ and COPC

Because the point block is uncompressed, LAS files are large. LAZ is the losslessly compressed form, produced by laszip: it re-encodes the same points (predicting each field from the previous point and entropy-coding the residual) into roughly 10–20% of the LAS size, and decompresses back to a byte-identical LAS. Nothing is lost, so LAZ is the standard for storage and transfer, and tools convert to LAS only when a program needs the uncompressed form. The newer Cloud-Optimized Point Cloud (COPC), also a .laz, reorganises the compressed data into a spatial octree so a viewer can stream just the region and detail it needs over HTTP. Other point-cloud formats you may convert to or from include the ASTM .e57 exchange format and plain-text .xyz, both of which trade LAS's compact fixed-width records for wider compatibility at the cost of size or metadata.

Frequently asked questions

Why does a LAS file start with "LASF"?

The four bytes 4C 41 53 46 ("LASF") are the File Signature field at offset 0 of the Public Header Block. A reader checks them first to confirm it is a binary LAS point cloud before trusting the offsets and counts that follow. If a .las file instead begins with readable text such as ~Version, it is a Log ASCII Standard well log, an unrelated format that happens to share the extension.

Why are coordinates stored as integers instead of decimals?

Each point keeps X, Y and Z as 32-bit integers, and the header supplies a scale factor and offset that convert them back to real-world units (real = int × scale + offset). Integers are four bytes, compress better than doubles, and enforce one uniform precision across the whole file. The scale (for example 0.001) fixes that precision.

What changed about point counts in LAS 1.4?

Earlier versions stored the number of point records as a 32-bit integer, capping a file at about 4.29 billion points. LAS 1.4 added 64-bit point-count fields to the Public Header Block, so a single file can hold far more, and it moved large records into Extended VLRs after the point block.

References

• ASPRS — LAS file format specifications
• Library of Congress — LAS (LASer) File Format, Version 1.4
• CloudCompare — open-source point-cloud viewer

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.