fix(render): strip NULL bytes from readStream output to prevent email truncation

[yufeikang]

Summary

readStream() in the Node.js render path can produce NULL bytes (U+0000) in the output when React's streaming renderer splits chunks at multi-byte UTF-8 character boundaries. Email clients (Gmail, etc.) treat NULL as a string terminator, causing emails to be silently truncated mid-content.

Problem

The Node.js readStream() uses TextDecoder with { stream: true } to decode chunks from React's streaming renderer (renderToReadableStream / renderToPipeableStream). When multi-byte UTF-8 characters (Japanese, German umlauts, Cyrillic, etc.) happen to span chunk boundaries, NULL bytes appear in the decoded string.

The pretty() function already handles this with str.replaceAll("\0", "") (source), but the default (non-pretty) render path returns the result without stripping NULLs.

Impact: Emails containing non-ASCII text are randomly truncated depending on where chunk boundaries fall. The browser version of readStream is not affected because it collects all chunks first and decodes them in a single pass.

Related Issues

• Unexpected, unredable characters in generated HTML #1667 — Unexpected, unreadable characters (Cyrillic Ü → \ufffd) in generated HTML
• Email content gets cut before umlauts #1932 — Email content gets cut before umlauts

Fix

Strip NULL bytes from the readStream() return value — same approach as pretty() already uses.

Test

Added a regression test that renders a large template with Japanese, German, Russian, and Korean multi-byte characters and asserts no NULL bytes appear in the output.

---

Summary by cubic

Strip NULL bytes from Node render readStream output to prevent emails from being cut off when streaming multi‑byte UTF‑8 characters. Ensures non‑ASCII emails render fully in clients like Gmail.

• Bug Fixes
  • Strip U+0000 from readStream output in the Node path to match pretty() behavior.
  • Add regression test with multi‑byte content to ensure no NULLs and correct text.
  • Addresses truncation issues reported in Unexpected, unredable characters in generated HTML #1667 and Email content gets cut before umlauts #1932.

^{Written for commit cccf6c3. Summary will update on new commits.}

[changeset-bot]

🦋 Changeset detected

Latest commit: cccf6c3

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@react-email/render	Patch
@react-email/components	Patch
playground	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

@yufeikang is attempting to deploy a commit to the resend Team on Vercel.

A member of the Team first needs to authorize it.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/resend/react-email/@react-email/render@2954

commit: cccf6c3

[cubic-dev-ai]

No issues found across 2 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

[yufeikang]

CI Test Failures — Not Related to This PR

The 2 snapshot test failures are caused by example.com changing its HTML (added </head> closing tag, changed </p> tags), which breaks the hardcoded snapshots.

Evidence that this is unrelated to our changes:

• src/browser/render-web.spec.tsx — we did not modify this file at all, yet it fails with the same snapshot mismatch
• Both failures are in the Suspense test that fetch("example.com") at runtime and compares against a stored snapshot
• The main branch last ran Tests on Feb 6 and passed — example.com must have changed its HTML after that date

The failing tests:

1. render-node.spec.tsx > "that it properly waits for Suspense boundaries to resolve before resolving"
2. render-web.spec.tsx > same Suspense snapshot test

These will continue to fail on any PR until the snapshots on main are updated.