A LAS file (.las) is the standard way to store a LiDAR point cloud. The format is published by the American Society for Photogrammetry and Remote Sensing (ASPRS) and has been the interchange format for airborne, mobile and, increasingly, drone LiDAR since 2003. Nearly every scanner exports it and nearly every piece of geospatial software reads it.
It is a binary format, and a simple one: a fixed header, a list of metadata records, then millions of identical fixed-size point records laid end to end. That simplicity is why it has lasted. It also means that almost everything worth knowing about a file is in its first few hundred bytes.
What is inside
| Section | Size | What it holds |
|---|---|---|
| Public header block | 227, 235 or 375 bytes | Version, point format, point count, scale and offset, bounding box, creation date, generating software, where everything else is. |
| Variable length records (VLRs) | Any number, up to 64 KB each | Coordinate system, LAZ parameters, extra-bytes descriptions, classification lookup, anything a vendor wants to attach. |
| Point data records | 20 to 67 bytes each, times the point count | One record per laser return. The layout is fixed by the point data record format. |
| Extended VLRs (EVLRs) | LAS 1.4 only; any size | Records too large for a VLR — waveform data, the COPC hierarchy — placed after the points. |
The header
The header begins with the four bytes LASF, then the version, then a run of fields that describe the file. The ones that matter day to day:
- Version — major 1, minor 0 to 4. Decides the header size and which point formats are legal.
- Point data record format — a single byte choosing one of eleven record layouts. It decides whether the points carry GPS time, colour, near-infrared or waveform data, and how many classes and returns they can express. See LAS point formats.
- Point count — 32-bit before 1.4, 64-bit from 1.4, with the old field kept for compatibility and zeroed when the count or format exceeds what it can hold.
- Scale and offset — three of each, turning stored integers into coordinates. See below.
- Bounding box — minimum and maximum X, Y and Z, as doubles. Cheap to read and usually, though not always, correct.
- Generating software and creation date — free text and a day-of-year pair. Useful for provenance, if the writer filled them in.
How coordinates are stored
Coordinates are not floating point. Each X, Y and Z is a signed 32-bit integer, and the real value is integer × scale + offset using the scale and offset from the header. A scale of 0.01 stores coordinates to the centimetre; a scale of 0.001 to the millimetre. The offset shifts the integer range onto the survey area, so that a projected easting in the hundreds of thousands of metres still fits in four bytes.
Two consequences. The precision of a LAS file is a header choice, and a writer that picks a scale of 0.000001 has not made the data more accurate — it has made it less compressible. And a scale of zero, or an offset far from the data, produces a file whose integers cannot be turned back into positions, which is one of the things an inspector should check for.
The coordinate system
The header has no field for a coordinate reference system. It lives in a VLR instead: for LAS 1.4, an OGC WKT string under user ID LASF_Projection, record 2112, with bit 4 of the Global Encoding field set to say the WKT is authoritative; for earlier versions, GeoTIFF keys in records 34735, 34736 and 34737 — the same key directory a GeoTIFF carries, written out flat.
A file may carry both, one, or neither. Neither is common in drone exports and in anything that passed through a tool that dropped records it did not understand. A file with no CRS is not broken, but its coordinates are numbers without a declared meaning, and any coordinate system assigned downstream is an assumption.
The point records
Every point occupies the same number of bytes, so the millionth point is at a known offset without reading the first 999,999. A format 6 record, the LAS 1.4 baseline, is 30 bytes: position, intensity, return number and count, classification, flags, scanner channel, scan angle, user data, point source ID and GPS time. Formats 7 and 8 add colour and near-infrared. The classification codes have their own article.
Versions
| Version | Year | Header | Point formats | What it added |
|---|---|---|---|---|
| 1.0 | 2003 | 227 B | 0, 1 | The original. |
| 1.1 | 2005 | 227 B | 0, 1 | The standard classification table; point source ID. |
| 1.2 | 2008 | 227 B | 0–3 | RGB colour (formats 2 and 3); GPS time type flag. |
| 1.3 | 2010 | 235 B | 0–5 | Waveform packets (formats 4 and 5). |
| 1.4 | 2011 | 375 B | 0–10 | 64-bit counts and offsets, extended VLRs, WKT coordinate systems, formats 6–10 with 256 classes and 15 returns. Revisions through R15 (2019) refined the class table. |
LAS 1.4 is the current version and the right default for new data. The older versions remain in wide circulation because national archives were built with them and because some software was slow to catch up; a 1.2 file is still readable by everything and still adequate for a great deal of work, as long as thirty-two classes and five returns are enough.
LAS and its relatives
| Format | Relationship to LAS | Use it for |
|---|---|---|
| LAZ | LAS, losslessly compressed with LASzip. Same header, same records, a tenth of the bytes. | Storage, transfer, archives. Anything at rest. |
| COPC | A LAZ 1.4 file whose points are arranged in an octree with an index record, so parts of it can be fetched over HTTP. | Serving point clouds from cloud storage to viewers. |
| E57 | Unrelated (ASTM). An XML-described container built for terrestrial scanners, with per-scan poses and imagery. | Exchange between scanner software; convert to LAS for GIS. |
| PLY, XYZ, PCD | Unrelated. Generic point formats with no standard metadata or coordinate system. | Graphics and robotics pipelines. |
The choice between LAS and LAZ is covered in LAS vs LAZ. The short version: keep LAZ, and decompress to LAS only for a tool that insists.
Opening a LAS file
LAS is the one format every GIS, CAD and point cloud package agrees on, so opening it is rarely the problem. For a look at the data without installing anything, the viewer on this site opens LAS and LAZ in the browser, and nothing is uploaded.
Inspect a LAS file's header and records — version, point format, coordinate system, every VLR decoded, and a check of whether the header agrees with itself. It reads only the first few kilobytes, so a 20 GB file takes the same instant as a 2 MB one, and it works on a URL without downloading the points.
Things that go wrong
- No coordinate system. The most common defect in delivered files. The data is fine; the meaning is missing. Ask the producer, and do not guess from the magnitude of the coordinates.
- Point format newer than the version. A "LAS 1.2" file with point format 6 is not valid, and strict readers refuse it. Some exporters produce exactly this.
- Stale counts. The points-by-return table and the legacy 32-bit count are easy to leave unpopulated or wrong; software that trusts them shows a different number of points than is actually there.
- A bounding box that lies. The header extents are written by the producer and not verified by anyone. A file cropped by a tool that did not rewrite the header keeps the old box.
- Classification that was never done. The header cannot tell you. Colour by class in the viewer.