mlightcad/cad-viewer: a browser-only DXF/DWG viewer that exports drawings as standalone HTML

What mlightcad/cad-viewer solves, and who ends up using it

Most browser CAD viewers upload the drawing to a server, parse it there, and stream back geometry. mlightcad/cad-viewer does the opposite. The README describes it as "the first web-based DXF/DWG viewer and editor in the world that operates entirely in browser, without relying on any backend services", with parsing, geometry processing and rendering all happening on the client. For anyone handling drawings under an NDA, or working on a machine with no network path to a rendering service, that changes the deployment question from "which cloud region" to "which static host".

The audience follows from that constraint. Teams embedding a drawing preview in a CMS, a Notion page or a WeChat article can point an iframe at a file URL and let the visitor's browser do the work. Engineers who need to hand a drawing to a client who has no CAD software get a second use case: the export to a single self-contained HTML file. The README states that the downloaded .html embeds the drawing snapshot and a lightweight viewer runtime, so the recipient can pan, zoom, toggle layers and measure distances in any modern browser with no CAD app, no server and no install. That artifact is the part of the project with the fewest direct equivalents.

It is not a drafting tool. The editing surface described in the README is selection and erase, plus review tools such as measure and annotate. If your workflow needs to draw new geometry, dimension it, and round-trip the result to a DWG that AutoCAD opens cleanly, this is the wrong layer of the stack.

How the browser-only pipeline is put together

The repository is a pnpm workspace with several packages under packages/, and the split matters more than the marketing line. @mlightcad/cad-simple-viewer is the modular core that plugins attach to. @mlightcad/cad-viewer is the full-featured application built on top of it. A separate CLI package, @mlightcad/cad-simple-viewer-cli, drives headless export, and there are example applications for the full viewer, the simple viewer, the HTML converter and a diff viewer.

Rendering goes through THREE.js, according to the feature list, with 3D rendering engines and optimization techniques for large drawings. The plugin system is the extension point: plugins implement the AcApPlugin interface and hook into the viewer lifecycle through onLoad and onUnload, typically to register commands, add UI, or wire export and import pipelines. If you have used an AutoCAD-style command registry, the shape will be familiar.

The architectural claim worth pausing on is "no backend required". That is true of the runtime, not of the whole product. The repository contains PROPRIETARY-PARSER.md and PROPRIETARY-PARSER.zh-CN.md at the top level, which means at least one parsing component carries terms distinct from the MIT licence on the workspace package.json. The README does not resolve how that notice interacts with redistribution of the exported HTML file. Anyone shipping this commercially should read those two files before assuming the MIT label covers everything.

Installing mlightcad/cad-viewer and running the viewer locally

The README lists two prerequisites: Node.js 24 or newer and pnpm 10 or newer. Clone the repository and install the workspace dependencies. The root package.json pins the package manager to [email protected], so a mismatched pnpm will warn.

git clone https://github.com/mlightcad/cad-viewer.git
cd cad-viewer
pnpm install

This produces a populated workspace with all packages linked. The install is the long step; the monorepo pulls dependencies for the viewer, the simple viewer, the CLI and the example apps at once.

Starting the full viewer or the simple one

Two dev targets exist, and the difference is not cosmetic. pnpm dev starts the full-featured viewer; pnpm dev:simple starts the simple viewer that the plugin architecture is built around. If you plan to write a plugin, start with the simple one, because that is where the AcApPlugin lifecycle is exercised without the extra application shell around it.

pnpm dev

# or the simple viewer
pnpm dev:simple

Both commands run through nx and print a local URL. Open it and load a .dxf or .dwg file to confirm parsing works before you touch any integration code.

The one-line embed and the standalone HTML export

The README gives a single-iframe example for embedding a drawing on a website. The file is fetched from your URL and parsed in the visitor's browser, so the drawing never passes through a third-party cloud.

<iframe
  src="https://mlightcad.com/embed.html?url=https://example.com/plans/floor.dwg&mode=review&toolbar=1"
  style="width:100%;height:600px;border:0"
  allowfullscreen>
</iframe>

The url parameter points at your own file, mode=review selects the review toolset, and toolbar=1 keeps the toolbar visible.

Exporting a drawing to a self-contained HTML file from the CLI

The root scripts include an export path that builds the CLI and runs it against a fixture, writing to a tmp directory. This is the fastest way to see what the offline artifact actually looks like without wiring up the UI.

pnpm export:html

The script builds @mlightcad/cad-simple-viewer-cli and runs it with -i packages/cad-viewer-example/e2e/fixtures/minimal-line.dxf, -s packages/cad-simple-viewer-cli/examples/export-html.scr, -o tmp and --mode read. The output lands in tmp/ as an HTML file you can open directly from disk with the network off.

Where the browser-only design costs you

Large drawings are the obvious pressure point. Everything the viewer needs has to arrive over the network and be held in browser memory, and the README's memory comparison is framed against traditional desktop tools rather than against server-side renderers. There is no documented streaming or tiling scheme, so a drawing that a desktop application opens from local disk has to be downloaded in full first. The README does not document a maximum file size, and it does not document rollback behaviour if a parse fails partway through.

The editing feature set is the second boundary. The documented operations are select, zoom, pan and erase, with mobile equivalents. There is no documented command for drawing lines, arcs, or dimensions, and no documented DWG write-back path. Treat the "editor" in the description as annotation and cleanup, not authoring.

Licensing is the third. The workspace package.json declares MIT, but the presence of PROPRIETARY-PARSER.md at the repository root signals that the DWG parsing component is not under the same terms. The README does not explain the practical consequence for a product that redistributes exported HTML files. That is a question for your legal review, not for this article.

How it differs from Autodesk Viewer and server-side rendering

Autodesk Viewer is the reference point most people already know, and the difference is architectural rather than feature-level. Autodesk's viewer is a cloud service: you upload the drawing to Autodesk's infrastructure, and the rendered result comes back to the browser. That brings collaboration features and format coverage, and it also means the drawing leaves your machine. mlightcad/cad-viewer inverts both halves of that trade. Nothing is uploaded, and nothing needs a service account, but you also get no hosted collaboration layer and no vendor-managed format pipeline.

The second alternative is a server-side renderer that converts DWG to SVG or PNG and serves the result. That approach keeps the browser light and works on thin clients, at the cost of running and scaling a conversion service. mlightcad/cad-viewer removes that service from your architecture entirely. The README also points to community projects built on the same core, including a Nextcloud app and an Electron AppImage for Linux, which is a useful signal that the packages are consumable outside the demo apps.

Maintenance cadence and upgrade cost

The last push to the default branch was on 2026-08-24, and the most recent tagged release, v1.6.3, carries the same date, with v1.6.2 on 2026-08-21 and v1.6.1 on 2026-08-18. Three patch releases inside a week suggests active work on a short cycle, and the presence of a .changeset directory indicates versioning is managed deliberately rather than ad hoc.

That cadence has a cost for integrators. Patch releases landing days apart mean the version you pin can fall behind quickly, and the README does not describe a long-term support branch or a deprecation policy for the plugin interface. If you build a plugin against AcApPlugin, budget for re-reading the API docs at cad-viewer.readthedocs.io, which the README describes as versioned, on each minor bump. The licence question from the previous section compounds this: a dependency you cannot freely redistribute is a dependency you want to pin and audit rather than track at head.

Editorial conclusion

Adopt mlightcad/cad-viewer when you need DWG/DXF viewing inside a web app or an offline artifact you can email, and when client-side parsing is a requirement rather than a preference. Skip it if you need round-trip editing of complex drawings or a fully permissive licence across every component, because the repository ships a separate PROPRIETARY-PARSER.md notice alongside the MIT licence. Before committing, read that notice, confirm Node.js 24 and pnpm 10 are available, and run pnpm dev:html-converter to check that the export path produces a file your recipients can open.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes