node-ipc picks its parser once per connection, and its strictest profile refuses Windows named pipes outright

The parser is chosen once, not polled per message

The most consequential design decision is stated in one sentence and everything else follows from it: the implementation selects its parser and hot-path handlers once, when each client or server is created, and does not poll a security flag for every message. The alternative, re-deciding per message, would put a branch on the hot path of every single frame. So the cost moves to setup: you set the profile before calling any of the connect or serve functions, and changing it later means creating a new connection. There are four profiles and each states its own boundary in one sentence. The raw profile does no framing, no JSON parsing and no message checks at all, letting buffers pass straight through to the data event for a caller who owns the protocol. The fast profile adds envelope encoding and delimiter framing, and turns malformed JSON into a protocol error that closes stream connections. It is the default for trusted local peers. The guarded profile sits between the two and is the one aimed at anything less uniform. Setting a profile looks like this:

ipc.config.parser = 'guarded';
ipc.config.maxMessageSize = 1024 * 1024;
ipc.config.maxPendingBytes = 8 * 1024 * 1024;

The two size settings travel with the profile because they only mean something once framing is happening. A raw connection has no frames to bound.

The assured profile refuses a Windows named pipe it cannot verify

The strictest profile adds a required allow-list of event names on top of everything the guarded profile already checks, which includes frame size, pending stream writes, event names, reserved and prototype names, the envelope, and timing for incomplete messages. It also imposes two conditions that are stated as requirements rather than recommendations. Network use requires mutually authenticated TLS. And each Unix local server endpoint has to be a direct child of the secure socket root. Then there is the exclusion: the built-in Windows local service is rejected outright, because the library cannot prove its named-pipe access control list. That is a capability gap admitted rather than papered over, and it means the strictest profile is simply unavailable on the Windows local transport. The profile is also explicitly described as a building block rather than a certification, which is the honest framing for anything that can only verify what it was told.

Native ES modules only, and require works anyway on 22.13

The package ships native ES modules only. Node loads the same entry point through import or through synchronous require, and no transpiled CommonJS bundle is generated at all. That works because Node.js 22.13 added native support for requiring an ES module, which the documentation links directly, so the CommonJS entry point is a property of the runtime rather than a second build artifact. The consequence for you is a hard runtime floor, declared in the package manifest as well as in the documentation: Node.js 22.13.0 or newer. If you are on an older Node, there is no fallback bundle to reach for. The manifest also declares the package side-effect-free, which matters for bundlers even though this is not a browser library, and it exposes only three entry points: the module itself and two parser subpaths.

Native ESM does not mean it runs in a browser

The documentation goes out of its way to disambiguate a phrase that would otherwise be misleading, and the clarification is worth repeating because the shortcut is common. Native ESM means Node loads the one JavaScript implementation without needing a transpiler. It does not mean native-browser ESM. The JavaScript package is Node.js-only: it is built on Node's raw TCP, TLS, UDP, Unix-domain socket and Windows named-pipe APIs, plus filesystem, operating system, process and buffer APIs, and it is not supported in browsers with or without a bundler. The documentation website's own browser code is a separate thing and is not part of the package runtime. So a project that reads the module specification and assumes a browser target will find that the dependency graph stops at the first Node built-in it reaches.

Version 13 was never published, and 12 to 14 took two years

The release history has a gap that matters when you are pinning. Version 14.0.0 shipped in August 2026. Before it, version 12.0.0 from August 2024, and before that 10.1.0 from January 2023. Version 13 was never published at all, and the documentation names version 12 as the legacy Node release line that remains available. So the version numbers do not correspond to a cadence; there is no 13 to fall back to and the gap between the two majors you can actually install is roughly two years. The install guidance follows from that posture. All three ecosystems are given as an exact version pin rather than a range, with the explicit instruction to use an exact reviewed version and not a mutable tag or version range for security-sensitive deployments, which is unusual specificity to find in a readme for a communication library.

The three implementations guarantee different things

Three packages are published from one source and share the event envelope and delimiter framing across local sockets, TCP and UDP, but the guarantees are not symmetric. The JavaScript package is the only one with the four codec profiles including the raw pass-through, and the documentation says plainly that these transport guarantees are Node.js-specific. Rust shares the codec profiles but requires the caller to establish and verify the transport boundary, and the crate supplies TCP, UDP, Unix-domain sockets, Windows named pipes, raw bytes and the fast, guarded and assured codecs, while applications supply their own verified TLS stream because the crate deliberately does not choose or reimplement cryptography. That same principle shapes the C# package: it targets .NET 8 with no package dependencies and mirrors the JavaScript facade, offering async TCP and TLS, both UDP versions, Unix sockets, Windows named pipes, the same codec set, plus reconnect and synchronous request queues.

The test suite counts cases per language and gates interop separately

Testing is described in exact counts and with named commands, which tells you what is actually verified rather than what is aspirational. The Node test run covers 195 correctness cases, native V8 coverage, both module loaders, an installed-package smoke test and benchmark validation, writing reports into a coverage directory. The coverage tool is a separate dependency that provides native V8 coverage for the ES module suite with no transpilation and no bundling, and there is a command that hosts the report locally on a loopback address. The Rust side runs 38 cases through its own native runner, and the C# side runs its exact case inventory in Release configuration. Between Node and Rust there is a separate two-direction interoperability gate as its own command, which is the piece that would catch a framing change that each language's own tests accept. The examples directory is organised the same way, by transport rather than by feature, with separate directories for TCP, TLS, UDP, clustered Unix sockets, raw buffers, and the combined Unix and Windows socket path. Two other paths show up in the grammar as well: the module exports its event parser and its message parser as named subpath entries, so a consumer that only needs to parse rather than connect can import them without pulling in the transport layer.

Editorial conclusion

Use node-ipc if you need one message format across a Node.js service and a Rust or C# side, since the envelope and framing are shared rather than reimplemented per language. Pick your profile from the trust boundary rather than from habit: the fastest profile does no framing at all, and the strictest one turns off a local transport it cannot vouch for. Do not reach for it in a browser, because the JavaScript package is built on Node's socket and buffer APIs and is unsupported even with a bundler. Before deploying, note that version 14 needs Node.js 22.13.0 or newer with no CommonJS bundle, version 13 was never published, and the guidance is to pin an exact reviewed version rather than a range.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes