IES Photometric Files Explained: What an .IES File Includes & How Designers Use It
Most “IES photometric files” are treated like truth. They’re not. Here’s what an .IES file really contains, how designers actually use it, and where bad photometric data quietly wrecks projects.
People fake photometrics. An IES lighting file is just text, which means it’s cheap to generate, easy to copy, and painfully easy to “massage” until the lux plot looks like what sales promised—then it gets shipped as a photometric data file that everyone downstream treats as a contract. So who pays when it’s wrong?
Here’s the uncomfortable scale of why any of this matters: U.S. lighting used 244 TWh in 2020—about 14% of total U.S. electricity use, per DOE’s 2020 U.S. Lighting Market Characterization (published April 2024). That’s not a rounding error; that’s a policy target, a utility incentive magnet, and a procurement blood sport.
Table of Contents
What an .IES file includes (LM-63), in plain terms
An IES file format (LM-63) is basically two parts:
Header + metadata (the “who, what, tested where” story)
Photometric payload (the numbers: candela values across angles)
If you only remember one thing, remember this: the payload is the light distribution curve as math, not a pretty diagram.
The header is where the lies start
In a clean IES photometric file, the header tells you:
Manufacturer / luminaire catalog number (often [MANUFAC], [LUMCAT])
Test lab or test ID ([TEST], sometimes [TESTLAB])
Lamp lumen rating ([LAMPLUMENS]) and multiplier(s)
Photometric type (Type C is common for architectural luminaires)
Geometry hints (luminaire dimensions, or “0” if they didn’t bother)
A quick reality check I use: if the file has vague metadata, missing test identifiers, and generic “LUMINAIRE=LINEAR” labeling, I treat it like an unlabeled chemical drum. Might be fine. Might be a mess.
If you’re sourcing spec packs from a vendor, the fastest path is to demand a proper submittal bundle (IES/LDT + cut sheet + lab report). The site’s own LED lighting IES files + spec-ready submittal resources is literally positioned that way—request model/SKU, get IES/LDT plus documentation.
The payload: candela grids, not vibes
The real meat is a grid of luminous intensity values (candela) over:
Vertical angles (0–180°)
Horizontal angles (0–360° or a subset with symmetry)
That grid is what DIALux evo, AGi32, Relux, and similar tools ingest to calculate:
Illuminance (lux/foot-candles)
Uniformity ratios
Spacing criteria
Sometimes glare proxies (and sometimes misleadingly)
If you want a mental model: an IES file is a measured “beam fingerprint.” Two fixtures with the same lumen output can behave wildly differently if optics differ—lens vs reflector vs louver cell depth, etc.
Case in point: a deep-cell, glare-controlled linear grille fixture is defined by its distribution and cut-off behavior. Example: this anti-glare surface-mounted linear grille light explicitly sells “deep-cell” glare reduction and controlled distribution—exactly the sort of product where the IES light distribution curve is the product.
How designers actually use IES files (and why they don’t trust you)
Designers use IES files to answer three questions that purchasing people pretend don’t exist:
1 “Will this hit target lux where it counts?”
Not average lux. Not a single point. The actual plane: workplane at 0.8 m, corridor at 0.0 m, vertical illuminance on a wall-wash, etc.
2 “Will this feel bad?”
Glare complaints don’t show up as a line item until after install. Then they show up as change orders, desk relocations, and “please add diffusers” panic.
That’s why adjustable systems like track are brutal: a tiny aiming change turns the IES distribution into either a clean accent or a retina punch. If you’re building layouts, you’ll live inside the photometrics of LED track lighting fixtures more than you’ll live inside the catalog.
3 “Can we defend this in approvals, rebates, and audits?”
This is where insiders stop being polite: an IES file often becomes supporting evidence in spec approvals. Many vendors openly frame “IES/LDT photometrics… generated from LM-79 lab data” as an approvals deliverable, alongside drawings and reports—exactly how this site describes its project documentation workflow.
And yes—controls matter now. In one DOE field validation (Hennepin County outpatient building, Minnesota), the project leaned on LED + networked lighting controls and cross-system integration; it also documents modeled potential lighting savings of 1.5 kWh/ft² (68%) and total cost savings $0.41/ft². That’s the financial pressure pushing teams to model, justify, and verify.
Hard truths: why bad IES files keep passing through “professional” workflows
Short version: incentives reward neat plots, not honest measurements.
Long version:
A photometric file can be “technically valid” and still wrong. Wrong CCT variant. Wrong optic. Wrong mounting height assumption baked into how people interpret it.
Symmetry abuse is common. If a fixture isn’t truly symmetric but the file is simplified as if it were, your wall-to-wall uniformity claims are fantasy.
Thermal reality never makes it into the IES. LED junction temp shifts output; drivers drift; optics yellow. The IES is usually captured at a lab condition, not your plenum at 45°C.
If you’re doing custom work (optics, anti-glare, driver/controls combos), treat photometrics as part of engineering—not marketing collateral. That’s why an OEM/ODM page that explicitly promises “spec-ready deliverables: IES/LDT photometrics (based on LM-79 test data)” is saying the quiet part out loud: photometrics are a deliverable you should demand, not a favor. OEM/ODM services with IES/LDT + LM-79 packs.
A fast QA checklist I use before I trust an IES file
Do this before you place 400 fixtures in Revit and pretend it’s real.
Metadata sanity: catalog number, optic, CCT, wattage, lumens—do they match the cut sheet?
Angle counts: do the vertical/horizontal angle arrays make sense for the optic type?
TILT: if it’s not TILT=NONE, read why. (Most architectural luminaires should be NONE.)
Lumen consistency: if the file claims 12,000 lm but the family spec says 8,000 lm at 4000K, something’s off.
Distribution smell test: “perfectly smooth” curves can be a sign of synthetic generation. Real measurements have character.
Software spot-check: import into DIALux/AGi32, run a simple room, confirm the plot behaves like the beam type.
Comparison table: IES vs other photometric deliverables
Deliverable
What it is
Where it works
What designers use it for
Common failure mode
.IES (LM-63)
Plain-text candela distribution + metadata
DIALux, AGi32, Relux, many BIM workflows
Calculations, spacing, verification
Wrong optic/CCT variant; “generic” data reused
.LDT (EULUMDAT)
Similar concept, common in EU workflows
DIALux/Relux (EU-heavy)
Same as IES, often requested in EU tenders
Version mismatches; incomplete metadata
BIM/Revit family + photometrics
Geometry + parameters + linked photometric
Revit-centric coordination
Coordination + basic analysis
Family geometry doesn’t match photometric source
Lab report (LM-79)
Test report of photometric/electrical performance
Approvals, procurement, compliance
Proof the photometric file is grounded
Report doesn’t match shipped SKU or optic
FAQs
What is an IES file?
An IES file is a plain-text photometric data file (LM-63) that stores a luminaire’s measured luminous intensity values (candela) across vertical and horizontal angles, plus metadata like lamp lumens, test identifiers, and geometry, so lighting software can calculate illuminance, uniformity, spacing, and distribution behavior.
If you’re “downloading IES files” just to make software stop complaining, you’re missing the point: it’s the input that drives your outputs.
What does an IES photometric file include?
An IES photometric file includes a metadata header (manufacturer, catalog info, lamp lumens, test fields, photometric type) and a numeric candela table sampled over defined angle arrays, which collectively define the IES light distribution curve that lighting tools use to compute lux/foot-candle results and layout performance.
If the header is vague, assume the candela table is suspect until proven otherwise.
How do designers use IES files in lighting design?
Designers use IES files in lighting design by importing them into calculation tools (e.g., DIALux/AGi32) to simulate illuminance on task planes and vertical surfaces, test spacing and uniformity, compare optics, and support spec approvals with defensible photometric outputs tied to a specific luminaire configuration.
And yes—this is why a “close enough” file is not close enough.
How can I tell whether an IES file is trustworthy?
A trustworthy IES file is one whose metadata, lumen values, wattage, optic, and CCT variant match the actual SKU and documentation, and whose distribution behaves plausibly when imported into software; ideally it’s traceable to a test identifier and supported by a relevant lab report rather than a recycled or overly generic curve.
If the vendor can’t map file → SKU cleanly, treat it as unverified input.
Where can I download IES files for LED fixtures?
You can download IES files for LED fixtures from manufacturer resource libraries or by requesting a project submittal pack that includes IES/LDT photometrics plus spec sheets and compliance docs, ensuring the file matches the exact optic/CCT/wattage variant you’re specifying rather than a “family average” placeholder.
If you’re tired of chasing mystery photometric data at 11:47 PM, stop asking “Do you have an IES?” and start asking “Do you have the IES for this optic, this CCT (3000K vs 4000K), this wattage bin, with a traceable test ID?”
