Two Years of ZeroRedact!
It's been two years since publishing my first NuGet package: ZeroRedact. This short milestone post looks at the past and what's ahead.
My C# redaction NuGet package, ZeroRedact [NuGet, GitHub], launched 1.0.0 on the 24th of September 2024. It's been written about on my blog before back in October 2024 where I focused on:
- What it did
- The project structure
- Safety via many unit tests
- The docs website
- A WASM demo site
I was stoked with the release! Finally, a professional, public, NuGet package made with my own two hands.
A nice coincidence is that two years hits 20,000 downloads with a slow, but consistent acceleration in people picking ZeroRedact up. Woohoo!

What's changed?
We've got upgrades:
- Deterministic NuGet builds
- Ever-improving docs and demo site
- More performant!
- Less memory usage!
IServiceCollectionregistration- New redaction types
- .NET 10 support
Performance is the fun one, so let's take the average redaction time across all string benchmarks (a blunt metric, yes) and we can see an improvement:

Is it my improvement? Nah, it's .NET 10 coming in with all the fun work in the background. While there have been micro-optimisations from my side, they get drowned out either from the noise when benchmarking, or when compared to the underlying .NET changes.
In fact, some have regressed, notably the email work. We don't even need to look at the redactor, even the validator benchmarks show a regression:

We're still taking ~2ns, but I'll look to fix that in the future. It was a fix at the time due to a change in how .NET handles email addresses and I wanted to follow to make sure I kept within the same ballpark of validation, but I threw away the SIMD work to achieve it. Lessons learned.
There were also some bug fixes. These are the worst part of publishing a package where I know people are using a version that has a little bomb. 2.0.0 was unlisted for this reason as it had a subtle bug in two email redaction types that would mutate a normally immutable string - real bad. Though there were less scary bugs such as for dotless email domains and too much redacting for 19 digit credit cards.
What's next?
4.0.0 is being cooked up. It will be a breaking change because I want to re-think the API surface and perhaps change how exceptions are thrown too. The rough full list is:
- The big one: removing the
ReadOnlySpan<char>overloads. Originally I put them in because a lot of .NET methods had overloads of these alongside strings but with implicit conversion of strings and it falsely advertising it didn't allocate when it does for the final string, I've opted to remove it. It also eliminates aref structscoping problem which now we don't have to think of at all. - Make dates faster. They're currently the most neglected in terms of performance
- Fix the email performance regression
- See what trade-offs can be made for memory vs performance (i.e. more pre-calculations for future O(1) work)
- If I'm really slow, then .NET 12 support (at the time of writing this, .NET 11 RC-1 is out)
To conclude
I've learned a lot from ZeroRedact, and it's exciting that it's used! I look forward to supporting it well into the future.