Rendering LiDAR Scans in the Browser Without Uploading Anything
Most point-cloud workflows still start the same way.
Install a desktop tool.
Import the scan.
Wait.
Inspect.
Measure.
Export.
That workflow makes sense when you are doing serious GIS, photogrammetry, survey processing, classification, or production work.
But there is another moment that is much simpler:
You just received a scan and want to know what is inside it.
Does it open?
Is it clean?
Does it have color, intensity, or classification?
Can I measure something quickly?
Can I show it to someone without making them install software?
That is the moment I wanted to improve with OpenLiDARViewer.
It is an open-source, browser-based LiDAR and point-cloud viewer built around one simple idea:
Drop a scan into the browser and inspect it locally.
No upload.
No account.
No desktop install.
No conversion step for supported formats.
Live demo: https://lidar.aurtech.mx/
GitHub: https://github.com/Aurtechmx/openlidarviewer/
The real goal: own the first 60 seconds
There are already great tools for point-cloud work.
CloudCompare is powerful.
QGIS is powerful.
Potree is excellent for publishing point clouds on the web.
Professional LiDAR software exists for a reason.
OpenLiDARViewer is not trying to replace those tools.
It is focused on a smaller, earlier step:
the first 60 seconds after you get a scan.
Before you process it.
Before you classify it.
Before you prepare a report.
Before you decide what workflow it belongs to.
Sometimes you just need a fast first look.
That sounds simple, but LiDAR data makes “just open it” surprisingly complicated.
Keeping the scan on the device
One thing I wanted from the start was simple:
The scan should not have to leave the user’s machine just to be inspected.
For LiDAR and 3D scan data, that matters.
A scan can represent a private site, a client project, a building, a terrain model, an industrial asset, or a research dataset. Uploading it to a random cloud viewer just to take a quick look is not always acceptable.
So OpenLiDARViewer runs client-side.
The browser loads the app, but the scan itself is read, parsed, analyzed, and rendered locally.
There is no backend parser.
No server-side preprocessing.
No cloud ingestion pipeline.
No “upload your file and wait.”
Just the browser, the GPU, and the file on your machine.
Supporting real-world scan formats
The viewer now supports common point-cloud and scan formats such as:
- LAS
- LAZ
- E57
- PLY
- OBJ
- GLB / GLTF
- XYZ
- CSV
That mix is intentional.
I wanted the same viewer to handle both:
- drone / aerial LiDAR
- phone and mobile 3D scans
Those worlds often feel separate, but in practice they are starting to overlap. People capture data from drones, phones, scanners, photogrammetry tools, and AR apps. A lightweight viewer should not care where the scan came from as long as the data can be parsed and rendered.
E57 support was especially important because it is a serious professional exchange format. It also brings more complexity: metadata, scan structure, transforms, optional attributes, and vendor differences.
Getting that kind of file working in the browser is not just a checkbox. It is an interoperability milestone.
Measurement had to become more than a demo feature
The first measurement tool was simple: pick two points and get a distance.
Useful, but limited.
The newer measurement workflow is more practical. It includes:
- distance
- polyline
- area
- height
- angle
- slope
- unit switching
- editable points
- clearer measurement sessions
It does make it more useful for quick inspection.
Scan intelligence: not just seeing the cloud
A point cloud viewer should do more than show dots.
When I open a scan, I want quick answers:
- How many points are in this file?
- What is the extent?
- What is the approximate density?
- Does it have RGB?
- Does it have intensity?
- Does it have classification?
- Are there invalid coordinates?
- Are there suspicious outliers?
- Does the decoded data match what the file claims?
That is why OpenLiDARViewer includes scan intelligence and validation modules.
The goal is not to replace professional QA/QC.
The goal is to give a useful first read before committing to deeper processing.
Seeing the scan matters.
Understanding whether the scan looks intact matters too.
Why the interface is more game-like than GIS-like
A lot of spatial tools inherit GIS interaction patterns.
That is fine for GIS users, but it can be intimidating for people who just want to move through a 3D scan.
OpenLiDARViewer uses a more direct navigation model:
- Orbit mode
- Walk mode
- Fly mode
- WASD movement
- mouse-look
- touch support on mobile
- point inspection
- saved viewpoints
The goal is to make the scan feel like a space you can enter, not just a dataset you loaded.
Orbit works well for objects and small sites.
Walk makes more sense for interiors or street-level scans.
Fly feels better for terrain, drone LiDAR, and wide-area data.
This is one of the parts I care about most because good interaction design can make technical data much easier to understand.
Mobile was not optional
At first, this kind of tool feels desktop-first.
Then reality shows up.
People want to open scans:
- on site
- on tablets
- on phones
- during a demo
- while moving between field and office workflows
Mobile support creates its own set of problems:
- touch controls
- viewport behavior
- limited memory
- smaller screens
- browser gestures
- GPU differences
- file picker behavior
A viewer that technically opens on mobile but feels terrible is not really mobile-friendly.
So mobile support became part of the direction, especially for phone scan exports and quick review workflows.
Feedback I am looking for
If you work with any of these areas, I would really value your feedback:
- LiDAR
- UAV mapping
- GIS
- photogrammetry
- 3D scanning
- WebGL / WebGPU
- point-cloud visualization
- browser-based technical tools
The most useful feedback would be:
- Does your file open?
- Does performance feel acceptable?
- Are the controls intuitive?
- Are the measurement tools useful?
- Does E57 behave correctly with your files?
- What format support is missing?
- What breaks?
- What would make this useful in a real workflow?
Live demo: https://lidar.aurtech.mx/
GitHub: https://github.com/Aurtechmx/openlidarviewer/
If the project is useful, a GitHub star helps. But real feedback from people who work with point-cloud data helps even more.
Final thought
The browser is becoming a serious runtime for technical software.
Not for everything.
Not for every workflow.
But for the first step — opening, inspecting, measuring, and understanding spatial data — it is starting to make a lot of sense.
That is the direction OpenLiDARViewer is exploring.