magick-wasm puts ImageMagick's format support inside the browser

Image processing without a callback to an API

The problem magick-wasm addresses shows up whenever a web application needs to do real image work. ImageMagick supports over 100 major file formats, and it is the tool most teams reach for when the input is an unusual format or the operation is something the browser canvas API does not do. The usual options are both compromises. Call a server that has ImageMagick installed, which means your image data leaves the browser and you now operate an image processing service. Or reimplement the operation in JavaScript, which means you do not have the format coverage.

magick-wasm removes the callback to an API. The README states that with magick-wasm you can use ImageMagick in your web application without doing a callback to an api. The library is the same ImageMagick code compiled to WebAssembly, so the format support and the operations come along with it, and the work happens where the data already is.

The audience is therefore frontend and full stack developers. If you are building an upload flow, a thumbnail generator, a format converter or an editor, and you need behaviour that matches what a server side ImageMagick would give you, this is the shortest route to it in JavaScript.

The same package covers the other side of the boundary too. The README says the library allows you to use ImageMagick in Node.js or Deno without installing ImageMagick on the system, which is the case where a container image wants to stay small, or where a team does not want a native dependency in a serverless function.

Two wasm binaries, exported by architecture

The npm package is called @imagemagick/magick-wasm, and the manifest shows a package that is prepared for several consumers at once.

It is an ES module package, and the exports map points at three things: the type definitions, the ES module entry point and a CommonJS build. The main field points at the UMD CommonJS file and the module field at the ES module file, so a bundler and a Node require call both resolve.

The wasm binaries are exposed as subpath exports, one per architecture:

        "./x64/magick.wasm": "./dist/x64/magick.wasm",
        "./magick.wasm": "./dist/x86/magick.wasm"

That naming is worth reading carefully. The x64 path is explicit, and the bare magick.wasm path resolves to the x86 build. If your deployment target is 64-bit, you are responsible for pointing the runtime at the x64 file.

The published files list is short: dist, plus the NOTICE file. That means the compiled JavaScript, the type definitions and the wasm binaries are what ship, and the notice about the underlying ImageMagick code travels with them. The repository itself also holds LICENSE, NOTICE, src/, tests/, a demo/ directory, a deno/ directory, a tools/ directory and an issue/ directory, so the package is assembled from several working areas rather than from a single source folder.

The build is vite plus a type definition bundler

The build script is one line and says most of the tooling story:

        "build": "vite build && dts-bundle-generator src/index.ts -o dist/index.d.ts --external-inlines @dlemstra/magick-native",

A vite build produces the JavaScript bundles, and dts-bundle-generator produces a single rolled up type definition file from the source entry point. The external-inlines flag for @dlemstra/magick-native tells the generator how to treat the native package, which is where the actual WebAssembly build of ImageMagick comes from. That native package is a devDependency pinned to a dated version, 2026.1010.1943, which encodes the day the native build was produced.

Tests run under vitest, and there is a second script that tests the built output rather than the sources, which is the check that matters for a package whose whole job is to work after bundling:

        "test": "vitest run",
        "test-dist": "node tests/dist/test-dist",

Other scripts cover the everyday chores. The demo script compiles and runs the demo project, the issue script does the same for the issue reproducer, lint runs eslint with a zero warning limit, and a prepare script runs npm-postinstall.mjs. There is also an update-index script in the tools directory, which suggests the public API surface is generated from an index file rather than hand maintained.

The configuration files match the toolchain: eslint.config.mjs for linting, tsconfig.json for TypeScript, vite.config.mts for the bundle, and a .devcontainer/ directory for a reproducible development environment.

Examples live in demo.ts and in a separate documentation repository

The README does not carry an API reference, and it says where the examples are instead. For examples on how to use magick-wasm, it points to the demo source in the repository, demo/demo.ts, and to a separate demo project hosted at the magick-wasm-docs repository.

That arrangement has consequences for an evaluator. The first real use of the library is demonstrated in TypeScript, in a file you can read before you install anything, and a full demo application exists that you can look at. But the API documentation itself is not in the repository, so the examples are the documentation. If you need a reference for the full surface, you are relying on the source and on the upstream ImageMagick documentation, to which the README links.

The repository layout supports that pattern. There is a demo/ directory with demo.ts and its own tsconfig.json, a separate deno/ directory for the Deno target, tests/ for the test suite, tools/ for the index generation script, and issue/ for a reproducer used to file issues. The .github/ directory, the CONTRIBUTING.md file and the eslint configuration show a project with the normal contributor plumbing.

For the deeper questions about what ImageMagick itself can do, the README points at the ImageMagick site, so the split is clear. The wasm build decides where the code runs, and ImageMagick documentation decides what the operations mean.

A 0.0.x version line that moves every few weeks

The version numbering is the biggest practical signal about the maturity of this package. The recent releases are 0.0.45 on 2026-10-18, 0.0.44 on 2026-09-30 and 0.0.43 on 2026-08-25, and the manifest records the version as 0.0.45.

Three releases in about two months, all on a 0.0.x line, means the author is publishing often and has not yet reached a 1.0 where the API would be considered stable. For a library whose purpose is to be a dependable substitute for a native tool, that is a real consideration. Any change in the API surface between patch numbers is possible, and the README's release notes link points at the GitHub releases page for 0.0.45, which is where the change record for each of these versions lives.

The project is clearly being worked on. The last push to the repository was on 2026-10-19, a day after the newest release, and the topics include hacktoberfest, which explains part of the activity around the 0.0.43 to 0.0.45 window. A devcontainer, a separate issue reproducer directory and an update-index tooling script all point to a maintained workflow rather than a one off port.

The dependency on @dlemstra/magick-native is the other thing to understand before you commit. Because the wasm binary is produced by that package and pinned by a dated version, upgrading ImageMagick inside the wasm build is a separate step from upgrading magick-wasm itself. The version number 2026.1010.1943 in the manifest is effectively the ImageMagick build you are getting.

Apache-2.0 for the wrapper, and a NOTICE that names the upstream

The licence is Apache-2.0, recorded in the package manifest and in the LICENSE file at the repository root, and the README badge links to a license.txt in the repository. The package publishes the NOTICE file alongside the dist directory, which is what makes the licensing position usable in practice: the notice about the underlying ImageMagick code is shipped with the binaries rather than left in the source repository.

The reason this matters is that magick-wasm is a wrapper around someone else's code. ImageMagick is a separate project with its own terms, and the fact that this project ships a NOTICE and an Apache-2.0 LICENSE is a signal that the licensing of the embedded code has been thought about rather than ignored. For a commercial deployment, read both the LICENSE and the NOTICE in the published package rather than the repository, since the published artefact is what your users receive.

There is a personal element in the project as well. The README asks for sponsorship through GitHub Sponsors, mentions an amazon gift card, and offers a PayPal link, and the author posts release and download information on Bluesky. That is normal for a one person project maintained as a public good, and it is also a fair signal about the bus factor: one maintainer decides the release schedule, and the 0.0.x version line is the visible consequence of that arrangement rather than a sign of neglect.

Where a native ImageMagick is still the better answer

There are situations where reaching for the wasm build is the wrong move, and they are worth naming before you install anything.

The first is a server that already has ImageMagick. A native install gives you the same format coverage, the same operation set and a much smaller deployment story, with no wasm binary to ship, no Node memory ceiling to reason about and no double build of the same library. Wrapping the native tool in your own service is the conventional answer, and it is often less work than adapting to an API that is still on 0.0.x.

The second is throughput. The wasm build runs the same C code, but it does so inside a JavaScript runtime, and the README makes no performance claim either way. If your pipeline converts thousands of images per minute, the native binary is the safer default and the wasm build is the thing to benchmark on your own workload, not the thing to assume is equivalent.

The third is delegation to external tools. ImageMagick can hand work to other programs for certain formats and operations, and a WebAssembly build has no system to delegate to. The README does not document which delegates are available in the wasm build, so if your workflow depends on that behaviour, verify it against your specific formats before committing.

The fourth is a large scale build system. If you need image processing inside a build pipeline across many machines, the native package is one apt install away, and the wasm build is an extra dependency to keep aligned with your runtime versions.

Editorial conclusion

Adopt magick-wasm if you need ImageMagick's file format coverage inside a browser application or in a Node.js or Deno service and you cannot install a system ImageMagick or call a remote image API. Do not adopt it as a drop-in replacement for a native ImageMagick on a server, and do not pin to it casually while it is still on a 0.0.x version, because the release numbers 0.0.43, 0.0.44 and 0.0.45 show an API that has not yet been declared stable. Before you build on it, read the demo source at demo/demo.ts and the separate magick-wasm-docs demo project, check which ImageMagick build the @dlemstra/magick-native dependency pins, and confirm the wasm binary for your architecture is the one the package exports, x64 for 64-bit and the x86 file for 32-bit.

Frequently asked questions

Official sources

1. dlemstra/magick-wasm on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases