When you're using an online dev tool, you've probably had this thought at least once: "This site isn't sending my JWT token off to some server, right?" That's a fair thing to wonder. Most web-based encoders, decoders, and calculators send whatever you paste into them to an external server for processing. Open the network tab and check — you might be surprised how many tools do exactly that.
This post uses CompuTools's browser-based dev tool suite as a jumping-off point to explain how WebAssembly (WASM) has changed the way online calculators work, and what that actually means in practice. This isn't a usage manual — it's about the technology itself and how to make better decisions when choosing tools.
What "Processed in the Browser" Actually Means
Even if a website says "all processing happens locally," there are two things worth verifying before you take that at face value.
First: is the calculation JavaScript-based or WASM-based? Hash functions and CRC calculations implemented in JavaScript can run entirely in the browser, but they come with performance limits and you'd need to separately verify the implementation's correctness. WebAssembly lets you compile code written in systems languages like C, Rust, or Go and run it at near-native speed inside the browser. The bigger deal here is that you can pull in well-established, battle-tested libraries rather than reimplementing algorithms from scratch.
Second: which features actually need a server? Parsing a TLS certificate or analyzing headers for an external URL requires the browser to connect to the target server directly — you can't do that fully locally. But CRC checksums, Base64 encoding, quaternion-to-matrix conversions, and JWT payload decoding are all pure math. No server needed, period.
CompuTools tools like the CRC Calculator and 3D Rotation Converter compile Rust code to WASM and run it in the browser. The algorithm implementation lives right inside the WASM module; when you input a byte sequence, JavaScript hands it off to the WASM function. Nothing shows up in the network tab.
How WebAssembly Changed Browser Calculators
WebAssembly (W3C standard, officially recommended in 2019) is, for practical purposes, a bytecode format that runs in web browsers. Two things matter:
Performance: It's roughly 5–20× faster than JavaScript for numerical operations. When you're computing SHA-256 hashes or CRC-64 checksums over files that are several megabytes, you feel that difference. The reason CompuTools's CRC Calculator can handle drag-and-drop of 10 MB files is precisely because WASM makes that practical.
Code reuse: You can compile existing, verified library code as-is. CRC algorithms, for example, need to exactly match the parameters defined in Greg Cook's CRC Algorithm Catalogue — poly, init, refin, refout, xorout, check, residue — or you'll get wrong answers. Rust's crc crate provides an implementation validated against that catalogue's test vectors, and WASM lets you bring that implementation straight into the browser.
Write your own CRC-32 in JavaScript and you're one subtle mistake away from getting the wrong table generation, botching the bit reflection, or applying XOR in the wrong order. Catching those bugs requires comparing against a reference implementation anyway.
Three Situations Where Local Processing Actually Matters
1. Debugging Sensitive Tokens and Keys
JWT debugging is the clearest example. A JWT is made up of three parts — header, payload, and signature — and the payload carries things like user IDs, permissions, and expiration times. In production, you'll often run into a situation where you need to figure out why a token is being rejected. Pasting that token into a random external site is, in many organizations, a security policy violation.
A WASM-based JWT decoder means your input never leaves the browser, so that concern goes away. Same for HMAC signature verification, where you have to input a secret key — local processing matters for exactly the same reason.
2. Protocol Engineering and Embedded Development
Assembling Modbus RTU frames, computing CAN FD checksums, debugging an AUTOSAR communication stack — all of these involve running CRC calculations repeatedly. The input data might be from prototype firmware or an internal communication format that isn't public yet.
One of the most common sources of Modbus RTU errors is CRC mismatch, and the root cause is almost always confusion between byte order (endianness) and algorithm variants. CRC-16/MODBUS uses poly=0x8005, init=0xFFFF, refin=true, refout=true, xorout=0x0000, and the result goes into the frame little-endian (low byte first). Use an algorithm with the same name but a different init value — like CRC-16/ARC with init=0x0000 — and you'll get a completely different result. The right approach is to always specify the exact variant and verify against the test vector (the check value) first.
For CRC-16/MODBUS, the check value (the result for the ASCII string "123456789") is 0x4B37. If your calculator gives you that, the algorithm is implemented correctly.
3. 3D Rotation Transforms and Coordinate System Debugging
In game engines, robotics, and 3D graphics work, transform errors between quaternions, Euler angles, and rotation matrices are notoriously hard to track down. ROS defaults to ZYX-order Euler angles. Unity uses YXZ. Three.js defaults to XYZ. And the same quaternion value means something completely different depending on whether the component order is x,y,z,w or w,x,y,z.
When you're debugging this kind of thing, you end up pasting quaternion values from a robot arm or camera IMU into an online tool. If that data is the internal state of an unreleased system, sending it somewhere external is a problem. That's why the 3D Rotation Converter closes the loop inside the browser with WASM — rotation matrix orthogonality checks, quaternion normalization, all of it.
The Misconception: "WASM = Automatically Safe"
One thing worth being clear about: just because a tool uses WASM doesn't mean every feature runs locally. A TLS analyzer that checks certificate chains for external domains has to open a TCP connection to those servers — there's no way around that. You have to evaluate each feature independently: which parts are local, which parts have external dependencies.
There's also the theoretical possibility that a WASM module contains malicious code. For open-source tools you can audit the source and build pipeline directly. For closed-source tools, about the best you can do is monitor the network tab. Full trust only comes from building and running the code yourself.
What to Check When Picking a Browser Calculator
To summarize, here are the questions worth asking when choosing an online tool that'll touch sensitive data:
- Does the network tab stay empty? This is the most direct check.
- Is it WASM or pure JS? Matters for both performance and implementation trustworthiness.
- Where does the algorithm implementation come from? Was it compiled from a verified library, or hand-rolled? If the latter, did they test against known test vectors?
- Which features require a server? Judge feature by feature, not tool by tool.
Using These Tools in Practice
CompuTools (compu-tools.com) offers 30+ tools including a CRC Calculator, Base64 Encoder, JWT Tool, 3D Rotation Converter, Unix Timestamp Converter, Regex Tester, and QR Code Generator, all running in the browser. Settings persist to local storage so your configuration is there when you come back.
The CRC tool supports 113 algorithms from CRC-3 through CRC-64 with a filter to find what you need quickly. It accepts hex, binary, decimal, and octal input, and lets you copy output in whatever combination of endianness and prefix style you need. For protocol implementation work, the recommended approach is to verify against CRC-16/MODBUS's check value (0x4B37) before applying the algorithm to real data.
For quaternion and Euler angle conversions, the 3D Rotation Converter lets you set rotation order and angle units and copy results directly into your code. Rotation matrix orthogonality checks and quaternion normalization are all handled inside the browser.
Getting in the habit of asking "where does the computation actually happen" — especially when your data is sensitive — is a small thing that cuts out unnecessary risk.
References
- WebAssembly Community Group, WebAssembly Specification — Official specification for the WebAssembly bytecode format and execution model
- W3C, WebAssembly Web API — W3C Recommendation for the browser WebAssembly API (2019)
- Greg Cook, Catalogue of parametrised CRC algorithms — Reference for CRC algorithm parameters (poly, init, refin, refout, xorout, check)
- IANA / Modbus Organization, Modbus Application Protocol Specification V1.1b3 — Modbus RTU frame structure and CRC-16/MODBUS algorithm specification
- RFC 7519, JSON Web Token (JWT) — IETF standard defining JWT structure (header, payload, signature) and claims
- Rust
crccrate, docs.rs/crc — Documentation for the Rust CRC implementation used in CompuTools's CRC Calculator - MDN Web Docs, File API — Reference for the Web File API that enables local file processing in the browser