If you work with well log data, you work with LAS files. The Log ASCII Standard is the most widely used format for storing and exchanging digital well log information in the oil and gas industry, and has been since 1989. It's conceptually simple — a plain text file with a header and a data table — but that simplicity is deceptive. The real-world LAS files you'll encounter are riddled with edge cases, spec violations, and vendor-specific quirks that can silently corrupt your analysis.
This guide covers everything you need to know about LAS files: how the format is structured, how the three versions differ, where real files deviate from the spec, and what to do about it.
The LAS File in 30 Seconds
A LAS file is a plain ASCII text file divided into sections. Each section begins with a tilde (~) followed by a letter identifying the section type. The header sections contain metadata about the well, the curves, and the logging parameters. The final section contains the actual numerical data in a whitespace-delimited table.
Here's the minimal structure of a valid LAS 2.0 file:
~VERSION INFORMATION
VERS. 2.0 : CWLS LOG ASCII STANDARD - VERSION 2.0
WRAP. NO : ONE LINE PER DEPTH STEP
~WELL INFORMATION
STRT.M 1670.0 : START DEPTH
STOP.M 1660.0 : STOP DEPTH
STEP.M -0.125 : STEP
NULL. -999.25 : NULL VALUE
COMP. ANY OIL COMPANY : COMPANY
WELL. ANY ET AL #12 : WELL
FLD. EDAM : FIELD
LOC. A9-16-36-8W3M : LOCATION
PROV. SASKATCHEWAN : PROVINCE
SRVC. ANY LOGGING COMPANY : SERVICE COMPANY
DATE. 25-DEC-1988 : LOG DATE
UWI. 100091604808W300: UNIQUE WELL ID
~CURVE INFORMATION
DEPT.M : 1 DEPTH
DT .US/M : 2 SONIC TRANSIT TIME
RHOB.K/M3 : 3 BULK DENSITY
NPHI.V/V : 4 NEUTRON POROSITY
~A DEPTH DT RHOB NPHI
1670.000 123.450 2550.000 0.450
1669.875 123.450 2550.000 0.450
1669.750 123.450 2550.000 0.450
That's it. A complete, parseable LAS file. Every section, every delimiter, every field has a defined purpose — which is what makes the format both powerful and fragile.
Section-by-Section Breakdown
~V — Version Information (Required)
The Version section must be the first section in the file. It contains exactly two lines:
VERS identifies which version of LAS the file conforms to. In practice, you'll almost always see 2.0. Despite LAS 3.0 being available since 1999, adoption has been extremely limited. The LAS 1.2 spec from 1989 still shows up in older archived files.
WRAP indicates whether wrap mode is enabled. When WRAP is NO, each row of data occupies a single line with no line length restriction (in updated LAS 2.0 — the original spec capped lines at 256 characters). When WRAP is YES, the depth value sits on its own line and data values wrap onto subsequent lines, each capped at 80 characters. Wrap mode was originally necessary because of early computing limitations. Modern files rarely use it, but parsers must still handle it correctly.
~W — Well Information (Required)
The Well section is required and must appear second. It contains metadata about the well and the data index. Four lines are mandatory:
STRT, STOP, and STEP define the start depth, stop depth, and step interval of the index channel. The STRT value must match the first depth value in the data section exactly (though formatting may differ — 1670.0 and 1670.000 are equivalent). STEP must be 0 if the depth increment is not perfectly constant throughout the file.
NULL defines the null value used when data is not available. The overwhelming convention is -999.25, but the spec allows any value. You'll occasionally encounter -9999, -9999.25, or 9999.00 in the wild.
The remaining lines — COMP, WELL, FLD, LOC, PROV/STAT, SRVC, DATE, UWI — identify the well, its location, and the logging service. These are technically not required to contain data, but leaving them blank makes the file nearly useless for database loading.
Every line in the header sections follows the same delimiter structure: the first dot in the line separates the mnemonic from the unit, the first space after that dot separates the unit from the value, and the last colon in the line separates the value from the description. Understanding this parsing rule is essential:
MNEM.UNIT VALUE : DESCRIPTION
^ ^ ^
| | last colon = description delimiter
| first space after dot = value start
first dot = unit delimiter
This means values cannot contain colons, and mnemonics cannot contain dots or internal spaces. These constraints are frequently violated in real files.
~C — Curve Information (Required)
The Curve section lists every curve present in the data section, in the order they appear as columns. The first curve must be the depth index (valid mnemonics: DEPT, DEPTH, TIME, or INDEX). Each line follows the same MNEM.UNIT VALUE : DESCRIPTION format as the Well section.
The number of lines in the ~C section must exactly match the number of columns in the ~A data section. A mismatch here is one of the most common and destructive LAS errors — it causes curves to be assigned to the wrong columns, producing data that looks plausible but is silently incorrect.
~P — Parameter Information (Optional)
The Parameter section stores additional metadata about the logging environment: mud properties, casing depths, tool configurations, environmental corrections, and other constants. The format is identical to the Well and Curve sections. This section is optional but valuable — it captures the logging context that's critical for accurate petrophysical interpretation.
~O — Other Information (Optional)
The Other section is a freeform text area with no structural requirements. It's used for comments, disclaimers, processing notes, and anything else that doesn't fit elsewhere. Parsers can safely ignore its contents, and many do.
~A — ASCII Log Data (Required, Must Be Last)
The data section contains the actual numerical values in a whitespace-delimited table. Columns correspond to curves in the order defined by the ~C section. Every value must be a floating-point or integer number — text values, dates in string format, and exponential notation are not supported in LAS 2.0.
When wrap mode is off, each line contains one complete row of data. When wrap mode is on, the depth value is alone on its line and subsequent data values wrap onto the next line(s), with no line exceeding 80 characters.
Any line in any section beginning with # is a comment and should be ignored by parsers. There should be no truly blank lines — use # to create visual spacing.
LAS Versions: 1.2, 2.0, and 3.0
LAS 1.2 (1989)
The original specification. Introduced the tilde-delimited section structure and established LAS as the industry standard. It had a 256-character line length limit and some ambiguities in delimiter handling that caused interoperability problems between different software packages. Files in LAS 1.2 format still exist in archives — especially data from wells logged in the late 1980s and early 1990s — but new files should never be written in this version.
LAS 2.0 (1992, Updated 2014 and 2017)
LAS 2.0 resolved the inconsistencies in 1.2 and remains the dominant version today, over 30 years later. The 2014 and 2017 updates clarified several points without changing the fundamental format: line length is now unrestricted in unwrapped mode, the depth value divided by the step value must be a whole number, rounding of depth values is not acceptable, and the only valid index mnemonics are DEPT, DEPTH, TIME, or INDEX.
LAS 2.0 has an important structural limitation: it can only store one well per file, and all data must be in a single flat table indexed to a single depth or time column. You cannot have multiple logging runs at different depth ranges, different sample rates in the same file, or array data where a single depth has multiple associated values.
LAS 3.0 (1999)
LAS 3.0 was designed to address these limitations. It supports multiple data sections within a single file, each with its own parameter and column definition sections. You can store logging data, core data, inclinometry, drilling parameters, formation tops, and test data all in one file. Each data type can have its own index and sample rate.
Despite these genuine improvements, LAS 3.0 adoption has been extremely limited. The reasons are practical: most petrophysics software was built around the simplicity of LAS 2.0's single-table structure, and the incremental benefit of multi-section support didn't justify the cost of updating existing toolchains. LAS 2.0 files are also much easier to visually inspect in a text editor — the entire file is a single, scannable table. When practitioners need to store the additional data types that LAS 3.0 supports, they typically use separate LAS 2.0 files or switch to DLIS format entirely.
One important note: LAS 3.0 is backward compatible with 2.0. Software that reads LAS 2.0 should be able to open a 3.0 file and at minimum parse the log data sections. The ~Other section from 2.0 is no longer permitted in 3.0 — any freeform data must go into a user-defined parameter or column data section.
The 10 Most Common LAS File Problems
These are the issues you'll encounter most frequently when working with real LAS files from multiple sources. They range from nuisances that cause warnings to critical errors that silently corrupt your data.
1. Column Count Mismatch
The problem: The number of columns in the ~A data section doesn't match the number of curves listed in ~C.
Why it happens: Curves are added to or removed from the data section during processing, but the header isn't updated to match. The Kentucky Geological Survey documented this as a systematic problem when files were exported from PETRA® — the software sometimes inserted a duplicate depth track into the data without adding a corresponding entry to the curve section.
The consequence: Every curve from the mismatch point onward is assigned to the wrong column. Your "gamma ray" data is actually density. Your "porosity" is actually resistivity. The values are real numbers in plausible ranges, so nothing flags an error — until your analysis produces nonsensical results.
How to detect it: Count the data columns in any row of ~A and compare to the number of lines in ~C. They must be equal. This should be the first check in any LAS validation pipeline.
2. Non-Standard Null Values
The problem: The file uses a null indicator that doesn't match the declared NULL value in the ~W section, or uses an unconventional null.
Why it happens: Processing software changes null representation without updating the header, or files from different sources use different conventions (-9999, 9999.00, -999.2500, 0.0, or even blank fields).
The consequence: Null values are treated as real measurements. A depth interval with no data gets plotted as a spike to -999.25 on your log display, or worse, gets included in statistical calculations without anyone noticing.
3. Depth Step Irregularities
The problem: The actual depth increment between consecutive rows doesn't match the declared STEP value, or varies inconsistently throughout the file.
Why it happens: Files are spliced from multiple logging runs at different sample rates, or rows are deleted during editing without updating STRT/STOP/STEP. Some tools log at irregular intervals by design, but the STEP field is set to a nominal value instead of 0.
The consequence: Software that assumes regular sampling (common in signal processing and interpolation routines) produces incorrect results. Depth-matched merges between multiple LAS files fail silently when the grids don't align.
4. Character Encoding Problems
The problem: The file contains characters outside the standard ASCII range — accented characters in well names, UTF-8 byte order marks (BOM) at the start of the file, Windows-1252 "smart quotes" in comments, or extended ASCII in operator names.
Why it happens: Files pass through systems with different locale settings. Text editors add BOM characters when saving. European or Latin American well names naturally contain accented characters that fall outside the 7-bit ASCII range.
The consequence: Parsers that expect strict ASCII choke on the first non-ASCII byte. The Python lasio library handles this gracefully (it uses chardet for encoding detection), but many other tools do not. A UTF-8 BOM (\xEF\xBB\xBF) at the beginning of a file is particularly insidious — it's invisible in most text editors but makes the ~V section marker unrecognizable to strict parsers.
5. Wrap Mode Confusion
The problem: The WRAP flag in the ~V section doesn't match the actual data format, or wrap mode is set to YES but not implemented correctly.
Why it happens: The WRAP flag is set to NO but the data section still uses wrapped formatting (or vice versa). Some tools set WRAP to NO regardless of the actual format. Others generate wrapped data that exceeds the 80-character line limit.
The consequence: The parser reads multiple depth points as a single row, or splits a single row across multiple depth values. The resulting data is garbled beyond recognition, but (again) consists of valid numbers, so automated checks that don't understand wrap mode will miss it.
6. Duplicate Curve Mnemonics
The problem: The ~C section contains two or more curves with the same mnemonic — for example, two entries both named GR, or two entries named CAL.
Why it happens: Files are merged from multiple logging runs where the same measurement was recorded in each run. The merge tool concatenates the curve headers without deduplicating.
The consequence: Software that accesses curves by name (rather than column position) returns the wrong curve or throws an ambiguous reference error. Which GR do you get? The answer depends on the parser implementation, and it may not be consistent.
7. Delimiter Violations in the Header
The problem: Header lines violate the MNEM.UNIT VALUE : DESCRIPTION delimiter rules — colons appear in the value field, dots appear in the mnemonic, or spaces are missing between the unit and value.
Why it happens: Freeform text like well names, company names, or dates naturally contain colons and dots. The delimiter rules were defined for machine parsing, but the files are often hand-edited by people who don't know the parsing rules.
The consequence: The parser misidentifies the boundary between the value and description fields. A well name containing a colon gets truncated. A date formatted as 12:30:00 gets parsed as three separate fields. The lasio library has battle-tested heuristics for these cases, but many simpler parsers do not.
8. Missing or Incorrect Index Channel
The problem: The first curve in ~C is not a valid depth or time index, or uses a non-standard mnemonic like MD, TVD, DEPT.1, or DEPTH_MD.
Why it happens: The 2017 LAS 2.0 update clarified that the only valid index mnemonics are DEPT, DEPTH, TIME, and INDEX. But many files predate this clarification, and even post-2017 files routinely use non-standard names.
The consequence: Software that validates index names strictly rejects the file. Software that assumes the first column is always depth works fine — until it encounters a file where the first column is something else entirely.
9. Unit Inconsistencies
The problem: The units declared for STRT, STOP, STEP, and the index curve in ~C don't match. Or depth units switch between meters and feet within the same file.
Why it happens: Depth curves are recorded in feet but the header was templated with metric defaults (or vice versa). Partial edits update some fields but not others.
The consequence: Depth scales are wrong by a factor of ~3.28. This is usually caught quickly in visual QC, but in automated pipelines that don't display the data, it can propagate through an entire analysis chain.
10. Data Section Contamination
The problem: The ~A section contains non-numeric content — text strings, date stamps, embedded comments without # markers, or rogue header-like lines mixed into the data.
Why it happens: Manual editing, file concatenation errors, or processing software that writes status messages into the data stream.
The consequence: Numeric parsers throw exceptions on the non-numeric values. Even one bad line in a file with 100,000 rows can cause a complete parse failure unless the parser has recovery logic.
How to Validate Your LAS Files
If you're working with LAS files from external sources — and especially if you're loading them into a database or using them as ML training data — validation before ingestion is essential. Here's a practical checklist:
Structural checks (automated): Verify that required sections exist in the correct order. Count ~C entries against data columns. Confirm STRT/STOP/STEP match the actual first row, last row, and increment. Check that WRAP mode matches the actual data format.
Content checks (automated with manual review): Flag non-standard null values. Detect duplicate mnemonics. Validate that index units are consistent across ~W and ~C. Scan for non-ASCII characters. Check for depth step irregularities beyond a tolerance threshold.
Semantic checks (manual or AI-assisted): Verify that mnemonic names map to expected measurement types. Confirm that curve units are physically plausible for the measurement type (density in g/cm³ or kg/m³, not in feet). Cross-check related curves for physical consistency (e.g., neutron porosity and density porosity should be in similar ranges).
The CWLS distributes LAS Certify, a free validation tool that checks structural compliance. The Python lasio library is designed to read as many LAS files as possible — including those with common errors — and provides useful warnings when it encounters non-compliant formatting. For production pipelines, both tools are worth integrating.
LAS in the Modern Data Stack
The LAS format was designed in 1989 for a specific purpose: exchanging well log curves between personal computers. It has succeeded at that purpose beyond any reasonable expectation — it's still the most common exchange format 36 years later.
But the limitations are real. One well per file. One data table per file. No array data support. No standardized curve naming. No built-in validation mechanism. These limitations don't make LAS a bad format — they make it a format that needs a robust processing layer between the raw files and your analysis environment.
That processing layer — parsing, validation, mnemonic standardization, unit normalization, quality flagging — is exactly where most petrophysics workflows leak time. It's the unglamorous plumbing that has to work before any of the interesting interpretation work can begin.
PetroCurve automates the front of the LAS processing pipeline: drop a LAS file, get standardized curve mnemonics matched to industry naming conventions, then view or export a clean LAS 2.0 file in seconds. Your data stays in your browser. Try it free →