Mislav Has / December 12, 2025

The Internet of Things continues to expand rapidly, yet the devices that form it remain highly heterogeneous in both hardware and software. Different processors, toolchains, and operating systems mean that getting the same code to run across a range of small, low-power devices is rarely straightforward. In practice, a new microcontroller often requires modifying or partially rewriting existing code just to keep everything working. Over time, this makes updates slow and maintenance expensive.

Because of this, there’s been increasing interest in using WebAssembly (WASM) beyond the browser, especially on edge and embedded devices. Although it started as a web technology, WASM has turned out to be a flexible way to run portable code safely. The appeal for IoT developers is simple: build the code once and then run it on different devices without having to fight each individual platform, while still keeping execution predictable and isolated in a sandbox.

But how well does WebAssembly actually perform on tiny microcontrollers with not gigabytes but kilobytes of RAM?

Our recent study [1] explores this question by benchmarking two lightweight WASM runtimes on three representative microcontrollers. The aim is to understand the practical limits, trade-offs, and opportunities of using WASM in truly resource-constrained IoT devices.

Figure 1. WebAssembly portability across resource constrained devices

Why WebAssembly Matters for IoT

WASM has become one of the most promising tools for addressing IoT heterogeneity. Its most important benefits are [2]:

Portability

Compile your code (C, C++, Rust) once into a WASM binary and run it on any device with a compatible runtime. There is no need to maintain multiple platform-specific builds.

Security

WASM runs in a secure sandbox, protecting the device from potentially harmful or untrusted modules. This is especially useful for IoT gateways that need to load dynamic functionality.

Compactness

The WASM binary format is small and quick to transfer or update, reducing the cost of over-the-air firmware upgrades.

Ahead-of-Time (AOT) options

Some runtimes can generate native machine code ahead of execution, which is very beneficial for devices too small for just-in-time compilation.

These benefits seem ideal for IoT, but the question remains: can WASM be efficient enough on tiny hardware?

Our experimental setup

To evaluate WebAssembly on constrained hardware, we benchmarked two lightweight runtimes: wasm3, a fast interpreter optimized for microcontrollers, and WAMR, a more feature-rich runtime supporting AOT/JIT and OS integration. These were tested on three popular MCUs: the Raspberry Pi Pico, ESP32-C6, and Nordic nRF5340. We measured execution time, energy consumption (using the Nordic PPK2), and memory footprint, using two workloads implemented in both C and Rust. The workloads consisted of bubble sort, representative of control-flow–intensive behavior, and CRC-16, representative of computation and bitwise-heavy execution, both mirroring operations frequently performed in IoT firmware such as sensor-data preprocessing, buffer arrangement, and checksum computation.

What We Found

Across all devices, the trade-off was clear: WASM brings portability and safety, but at a significant performance and energy cost compared to native execution. Native code remains the most efficient option. Across all platforms and workloads, native C was the fastest, consumed the least energy, and used the least memory. For instance, on the Raspberry Pi Pico, bubble sort (100 integers) required roughly 0.06 mJ in native C, compared with 3.11 mJ on wasm3 and 2.96 mJ on WAMR.

wasm3 is remarkably lightweight. It consistently used less memory and ran faster than WAMR across all devices. On the Pico, bubble sort took about 612 µs natively, 6,358 µs under wasm3, and 29,475 µs under WAMR, showing how wasm3’s minimal design benefits highly constrained MCUs.

WAMR trades performance for capability. Features like AOT compilation, multithreading, OS integration (e.g., Zephyr), and modularity make it a better fit for IoT gateways or larger microcontrollers. The trade-off is higher memory usage and slower performance in interpreter mode.

Energy measurements show WASM execution on microcontrollers can be 10–40× more energy-hungry than native code but may still be acceptable for small workloads where portability or sandboxing matter more.

Device architecture matters too: the ESP32-C6 executed wasm3 workloads far more efficiently than the Raspberry Pi Pico.

Is WebAssembly Ready for IoT?

Yes, but not as a drop-in replacement for native firmware. WASM is already practical and useful in several IoT scenarios:

✔ Cross-platform applications

One WASM binary can run across dozens of device families, hugely reducing development effort.

✔ Secure execution of dynamic modules

Industrial gateways, shared sensor nodes, and modular apps benefit from sandboxing.

✔ Simplified OTA updates

WASM’s compact binary format makes updates easier and safer.

✔ Unified toolchains

Developers can build IoT components in Rust or C++ and deploy broadly via WASM runtimes.

✘ Performance-critical, battery-sensitive workloads still need native code

For tight loops, real-time tasks, or ultra-low-power firmware, WASM isn’t ready, especially without AOT.

Where WebAssembly Goes Next

Our study highlights several promising directions:

• Evaluating AOT and JIT modes (could drastically improve performance)
• Testing additional runtimes (e.g., WasmEdge, Wasmer)
• Integrating WASM with real-time operating systems
• Hardware acceleration for WASM (actively researched)

As runtimes mature and microcontroller hardware evolves, the performance gap will shrink. We may soon reach a point where the gains in portability and security outweigh the overhead, especially for modular or dynamic IoT systems.

The work described in this blogpost: “WebAssembly on Resource-Constrained IoT Devices: Performance, Efficiency, and Portability,” was presented at ScaleSys at IoT 2025. The full paper is here: https://www.arxiv.org/abs/2512.00035

References

[1] Has, M., Xiong, T., Abdesslem, F. B., & Kušek, M. (2025). WebAssembly on Resource-Constrained IoT Devices: Performance, Efficiency, and Portability. ArXiv. https://arxiv.org/abs/2512.00035

[2] Ray, P.P. An Overview of WebAssembly for IoT: Background, Tools, State-of-the-Art, Challenges, and Future Directions. Future Internet, 2023, 15, 275. https://doi.org/10.3390/fi15080275