Which Crates Will Work Off-the-Shelf with WebAssembly?

It is easiest to list the things that do not currently work with WebAssembly; crates which avoid these things tend to be portable to WebAssembly and usually Just Work. A good rule of thumb is that if a crate supports embedded and #![no_std] usage, it probably also supports WebAssembly.

Things a Crate Might do that Won't Work with WebAssembly

C and System Library Dependencies

There are no system libraries in wasm, so any crate that tries to bind to a system library won't work.

Using C libraries will also probably fail to work, since wasm doesn't have a stable ABI for cross-language communication, and cross-language linking for wasm is very finicky. Everyone wants this to work eventually, especially since clang is shipping their wasm32 target by default now, but the story isn't quite there yet.

File I/O

WebAssembly does not have access to a file system, so crates that assume the existence of a file system — and don't have wasm-specific workarounds — will not work.

Spawning Threads

There are plans to add threading to WebAssembly, but it isn't shipping yet. Attempts to spawn on a thread on the wasm32-unknown-unknown target will panic, which triggers a wasm trap.

So Which General Purpose Crates Tend to Work Off-the-Shelf with WebAssembly?

Algorithms and Data Structures

Crates that provide the implementation of a particular algorithm or data structure, for example A* graph search or splay trees, tend to work well with WebAssembly.


Crates that do not rely on the standard library tend to work well with WebAssembly.


Parsers — so long as they just take input and don't perform their own I/O — tend to work well with WebAssembly.

Text Processing

Crates that deal with the complexities of human language when expressed in textual form tend to work well with WebAssembly.

Rust Patterns

Shared solutions for particular situations specific to programming in Rust tend to work well with WebAssembly.