Why truncate by bytes instead of characters?

File size limits, like an API's max upload size or a fixed-width storage field, are almost always specified in bytes, and a character count doesn't tell you the byte count once non-ASCII text is involved, since UTF-8 characters can take up to 4 bytes each.

What happens if the cut point falls inside a multi-byte character?

The tool backs off byte by byte until it lands on a valid character boundary, so the output is always valid UTF-8 text, never a truncated multi-byte sequence that would render as a broken or replacement character.

Does this add a suffix like '...' to show text was cut?

No, the output is the raw truncated bytes decoded back to text with nothing appended, matching how a byte-limited file write actually behaves.

Text File Truncator - Cut a File Down to a Byte Size

Overview

Introduction

An API or storage system that enforces a maximum file size in bytes doesn't care how many characters your text has, only how many bytes it encodes to.

This tool truncates text to a byte limit directly, so you can test or produce content that fits exactly.

What Is Text File Truncator?

A byte-based text truncator that cuts input down to a maximum number of UTF-8 bytes, distinct from a character-based truncator since multi-byte characters (accented letters, emoji, non-Latin scripts) take more than one byte each.

Everything runs locally in your browser using the standard TextEncoder/TextDecoder APIs.

How Text File Truncator Works

The input is encoded to UTF-8 bytes, and if that's already within the limit, it's returned unchanged; otherwise the byte array is sliced at the requested length.

Because slicing at an arbitrary byte position can land inside a multi-byte character's continuation bytes, the tool walks backward from the cut point while it detects a continuation byte (one matching the 10xxxxxx bit pattern), guaranteeing the final decode produces valid text.

When To Use Text File Truncator

Use it when you need to fit text into a hard byte limit, an API request size cap, a fixed-width database column, or a legacy format with a byte-count header.

It's also useful for testing how your own code handles truncation at an arbitrary byte boundary without corrupting multi-byte text.

Often used alongside String Truncator, Text File Slicer and File Corruptor.

Features

Advantages

Truncates by the byte count that actually matters for size limits, not misleading character counts.
Never splits a multi-byte character, avoiding corrupted output.
Runs entirely client-side with no upload required.

Limitations

Backing off to a character boundary means the result may be a few bytes shorter than the exact limit requested, never longer.
Doesn't account for combining characters or grapheme clusters made of multiple code points; it operates at the UTF-8 byte level.

Examples

Truncating text with a multi-byte character near the cut

Input

café (5 characters, 6 bytes since é is 2 bytes), maxBytes: 5

Output

caf

Byte 5 would land inside é's 2-byte encoding, so the tool backs off to byte 3, the end of 'caf', rather than emitting a broken character.

Best Practices & Notes

Best Practices

Set maxBytes to the exact limit your target system enforces, not an approximation based on character count.
Use Slice a Text File instead if you need an arbitrary start and end range rather than just a maximum from the beginning.
Verify the resulting byte size with Analyze JSON or a similar size-checking tool if the truncated text feeds into a stricter downstream system.

Developer Notes

The continuation-byte check tests `(byte & 0b11000000) === 0b10000000`, the standard UTF-8 bit pattern for a non-leading byte in a multi-byte sequence; backing off while this holds always lands on a byte that starts a new character (or the very start of the buffer).

Text File Truncator Use Cases

Fitting text into a hard API request size limit
Preparing content for a fixed-width byte field in a legacy format
Testing that your own truncation logic doesn't corrupt multi-byte characters

Common Mistakes

Truncating by character count (input.slice(0, n)) when the actual constraint is a byte limit, producing output that's still too large once encoded.
Manually slicing a byte array without checking for continuation bytes, which can corrupt the last character in the output.

Tips

If you need to preserve a trailing indicator like '...', account for its own byte length by lowering maxBytes accordingly before truncating.
Non-Latin scripts and emoji use more bytes per character, so the same maxBytes value will keep noticeably fewer of them than plain ASCII text.

Text File Truncator