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.

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.

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.

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.

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.

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

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