A LAS file has three parts: a fixed-size header, a sequence of point records, and — between them — thevariable length records. The header has a field for everything the format's designers knew would always be needed, and the VLRs carry everything else.
"Everything else" turns out to include the single most important piece of metadata in the file: the coordinate reference system. Which is why a data structure that sounds like an implementation detail is worth understanding, and why the most common way to damage a LAS file is to lose its VLRs.
Layout
| Part | Position | Notes |
|---|---|---|
| Public header block | From byte 0 | 375 bytes in LAS 1.4 |
| VLRs | Immediately after the header | Count given in the header |
| Point data records | From the point data offset | The bulk of the file |
| EVLRs | After the point data | LAS 1.4 only; located by a header offset |
The header states how many VLRs there are, but not where they end — a reader walks them in sequence, using each record's length to find the next. EVLRs are found differently: the header carries a byte offset to the first one and a count.
The VLR header
Every VLR begins with the same 54-byte structure:
| Bytes | Field | Purpose |
|---|---|---|
| 0–1 | Reserved | Unused. Not reliably zero in real files. |
| 2–17 | User ID | 16 characters naming who defined this record |
| 18–19 | Record ID | Which record it is, within that user ID |
| 20–21 | Record length after header | Payload size — 16-bit, so at most 65,535 |
| 22–53 | Description | 32 characters of free text, for humans |
The user ID and record ID together identify a record. The user ID acts as a namespace, so a vendor can define record 1 without colliding with anyone else's record 1. Two user IDs are reserved by the specification — LASF_Projection and LASF_Spec— and everything else is claimed by convention.
EVLRs, and why they exist
The 16-bit length field is the constraint that drove the addition of EVLRs in LAS 1.4. A payload cannot exceed 65,535 bytes, which is comfortable for a coordinate system and hopeless for, say, a full waveform packet store.
An EVLR has a 60-byte header, identical to a VLR's except that the length field is 64-bit. Combined with its position after the point data, that gives two distinct advantages:
- Size. The payload can be gigabytes.
- Appendability. Adding a VLR means shifting every point record to make room and rewriting the whole file. Adding an EVLR means writing at the end and updating one offset in the header.
That second property is what COPCexploits: its octree index is written as an EVLR after the points, because the index cannot be built until the points have been laid out.
The records you will actually meet
| User ID | Record | What it is |
|---|---|---|
LASF_Projection | 34735 | GeoTIFF key directory — the CRS as numeric keys |
LASF_Projection | 34736 | GeoTIFF double parameters |
LASF_Projection | 34737 | GeoTIFF ASCII parameters |
LASF_Projection | 2112 | OGC coordinate system WKT — the CRS as text |
LASF_Projection | 2111 | OGC math transform WKT — rare |
LASF_Spec | 0 | Classification lookup — names for class codes |
LASF_Spec | 3 | Text area description — free-text notes |
LASF_Spec | 4 | Extra bytes — describes additional per-point fields |
LASF_Spec | 7 | Superseded |
LASF_Spec | 100–354 | Waveform packet descriptors |
laszip encoded | 22204 | LAZ compression parameters — present in every LAZ file |
copc | 1 | COPC info — must be the first VLR in a COPC file |
copc | 1000 | COPC hierarchy — the octree index, always an EVLR |
Beyond these, vendor records are common and generally harmless: a processing tool records its settings, a scanner manufacturer stores calibration notes. They are unreadable without the vendor's documentation, and should be preserved rather than discarded, because a record you do not understand may matter to someone who does.
The projection record
The most important VLR in most files. Without it a point cloud has coordinates and no idea what they refer to — it opens, it looks completely normal, and it cannot be combined with anything.What is a CRS covers the consequences and the difference between the GeoTIFF and WKT forms.
One subtlety: a file may carry both a WKT record and GeoTIFF keys, and they may disagree. Bit 4 of the header's global encoding field says which should be believed. After a file has passed through several tools, that bit is not always correct — which is the kind of thing worth checking rather than assuming.
The Extra Bytes record
Genuinely useful and often misunderstood. LAS allows point records to be longer than the point format requires, with the surplus holding additional per-point values — a second intensity, an echo width, a confidence score, a deviation.
The Extra Bytes VLR is what makes those bytes readable.It describes each extra field in turn: name, data type, an optional scale and offset, units, a no-data value, and a description. Without it, a reader can see that the records are longer than expected and has no way to interpret the surplus — the data is present and meaningless.
This makes it the second most important record to preserve through a conversion, after the projection.
The laszip record
Every LAZ file carries one. It describes how the points were compressed: the chunk size, and which compressor applies to each field of the point record. A decompressor reads this before touching the data.
It is also the one record that should not survive a conversion unchanged. Decompressing LAZ to LAS makes it meaningless, soa correct LAZ to LAS converter removes it while keeping every other record — and a correct LAS to LAZ converter writes a fresh one.
Why conversion loses them
This is the practical reason to care about any of the above.
The obvious way to write a LAZ file is to hand your points to a compression library and let it produce the file. Several such libraries build their own header from the fields they need andcopy only the records they recognise — which meansLASF_Projection is dropped, along with Extra Bytes descriptions and every vendor record.
The failure has an unusually bad shape:
- The output file is valid and opens in every tool.
- Every point is present and correct.
- No error is reported, at conversion time or afterwards.
- The coordinate system is simply gone.
Nobody notices until the cloud is loaded beside something else and does not line up — often long after the original has been archived or deleted.
The converters here assemble the LAZ container themselves rather than delegating it to the compressor's writer, precisely to avoid this. The test suite checks a LAS to LAZ to LAS round trip byte for byte — public header, all VLRs and EVLRs, and every point record — across LAS 1.2, 1.3 and 1.4. How it works covers the mechanism, and it is the reasonLAZ to LAS andLAS to LAZ are safe to run on data whose CRS you care about.
Reading them
VLRs sit in the first few kilobytes of the file, so reading them costs nothing — no decompression, no point access.
Inspect the records in a LAS or LAZ file. It lists every VLR and EVLR with its user ID, record ID, payload size and recognised meaning, decodes the coordinate system from whichever record holds it, and works on a hosted file by URL — fetching only the beginning rather than downloading the whole thing.
What to check after any conversion:
- Is
LASF_Projectionstill present? - Does the CRS still describe the same system, in whichever form it now takes?
- If the input had Extra Bytes, is the record still there — and do the point records still have room for the fields it describes?
- Did the record count change unexpectedly?
Doing this once, immediately after converting, costs a few seconds and catches the failure while the original still exists.