JSON Minifier

JSON minification is the programmatic process of removing all unnecessary characters—such as spaces, tabs, and line breaks—from JavaScript Object Notation (JSON) data without altering its structural integrity or semantic meaning. This practice is absolutely critical in modern web architecture because it directly reduces payload sizes, thereby decreasing network latency, lowering cloud bandwidth costs, and accelerating client-side application performance. In this comprehensive guide, you will learn the precise mechanical workings of JSON minification, its historical evolution, the mathematical impact on network transmission, and the expert strategies required to implement it flawlessly in high-scale production environments.

What It Is and Why It Matters

JavaScript Object Notation, universally known as JSON, is the dominant data-interchange format of the modern internet, serving as the primary language that web servers, mobile applications, and databases use to communicate. By design, JSON is a text-based format that is intentionally easy for humans to read and write. To achieve this human readability, developers format JSON documents with structural whitespace: spaces after colons, line breaks after commas, and deep hierarchical indentation using tabs or spaces. However, computers and software parsers do not require any of this formatting to understand the data; to a machine, a continuously strung-together line of characters is just as legible as a beautifully formatted document.

JSON minification is the systematic removal of this human-centric formatting to produce the absolute smallest possible text footprint. Every single space, tab, and carriage return in a text file consumes exactly one byte of data in standard UTF-8 encoding. In a large, deeply nested JSON document, these formatting characters can account for 10% to 40% of the total file size. When an application transmits this data across the internet, those wasted bytes translate directly into wasted milliseconds of transfer time and wasted fractions of a cent in cloud provider bandwidth fees.

The importance of JSON minification scales linearly with the size of the application and the volume of its traffic. For a developer working on a local machine, the difference between a 100-kilobyte formatted file and a 70-kilobyte minified file is imperceptible. However, for a global enterprise processing 10,000 API requests per second, shaving 30 kilobytes off every response equates to eliminating 300 megabytes of unnecessary data transfer every single second. Over the course of a month, this prevents the transmission of nearly 777 terabytes of useless whitespace. By implementing JSON minification, organizations drastically reduce their Amazon Web Services (AWS) or Google Cloud Platform (GCP) egress costs, while simultaneously ensuring that end-users on slow 3G mobile networks receive their data significantly faster.

History and Origin

To understand the origin of JSON minification, one must first understand the birth of JSON itself. In the late 1990s and early 2000s, the standard format for data exchange was Extensible Markup Language (XML). XML was highly structured but notoriously verbose, requiring opening and closing tags for every single piece of data, which resulted in massive, bloated file sizes. In 2001, a software engineer named Douglas Crockford, alongside his colleagues at State Software, discovered a way to leverage the existing object literal notation of the JavaScript language to transmit data much more efficiently. Crockford formalized this discovery and registered the json.org domain in 2002, positioning JSON as the "fat-free alternative to XML."

By 2005, the introduction of AJAX (Asynchronous JavaScript and XML) revolutionized web development by allowing web pages to request data from a server without reloading the entire page. Ironically, developers quickly realized that using JSON instead of XML for these asynchronous requests was vastly superior because JavaScript engines could parse JSON natively and instantly. As the industry rapidly transitioned from SOAP/XML architectures to RESTful APIs utilizing JSON, the sheer volume of JSON transmitted across the internet exploded. Early JSON payloads were small, but as web applications evolved into complex Single Page Applications (SPAs) like Gmail and Facebook, JSON payloads grew from a few dozen bytes to several megabytes.

The concept of "minification" had already been popularized in the early 2000s for JavaScript and CSS files, driven by tools like JSMin (also written by Crockford in 2001) and later the YUI Compressor (2007). Developers naturally realized that the exact same principles applied to JSON. Since JSON is essentially a strict subset of JavaScript object syntax, early developers simply ran their JSON through existing JavaScript minifiers. However, as JSON became formalized under official engineering standards—specifically RFC 4627 in 2006, and later the definitive RFC 8259 in 2017—dedicated JSON minifiers emerged. These specialized tools were designed to be incredibly fast, operating strictly on the rules of JSON grammar without the overhead of a full JavaScript compiler, allowing servers to minify data dynamically in real-time just milliseconds before transmitting it over the wire.

Key Concepts and Terminology

To master JSON minification, you must be intimately familiar with the specific terminology used in data serialization and network transmission. These concepts form the foundational vocabulary required to architect efficient systems.

Whitespace Characters

In the context of JSON, whitespace is strictly defined by the RFC 8259 specification as exactly four specific ASCII characters: Space (U+0020), Horizontal Tab (U+0009), Line Feed (U+000A), and Carriage Return (U+000D). A JSON minifier's primary job is to locate and delete these four specific characters, but only when they appear outside of string values.

String Literals and Escaping

A string literal in JSON is any sequence of characters wrapped in double quotation marks ("). Inside a string literal, whitespace is considered sacred data, not formatting. For example, the space in "First Name": "John Doe" is structural whitespace before the string, but the space between "John" and "Doe" is data. Furthermore, JSON strings can contain escaped characters, denoted by a backslash (\), such as \" to include a quote inside a string. A minifier must flawlessly understand escaping to avoid accidentally modifying the data payload.

Serialization and Deserialization

Serialization is the process of converting an in-memory application object (like a Python dictionary or a Java Hashmap) into a flat string of JSON text so it can be transmitted over a network or saved to a disk. Deserialization is the exact reverse process: taking a minified JSON string and converting it back into a usable in-memory object. Minification is typically performed as the final step of serialization.

Abstract Syntax Tree (AST)

An Abstract Syntax Tree is a hierarchical tree representation of the syntactic structure of source code or data. While simple minifiers use basic character scanning, advanced minifiers parse the JSON into an AST first. This ensures the JSON is 100% valid before it is minified, allowing the tool to catch syntax errors (like a missing comma) rather than just blindly stripping spaces and producing a corrupted file.

How It Works — Step by Step

The mechanics of JSON minification rely on a computer science concept known as a Finite State Machine (FSM). Because a minifier cannot simply delete all spaces blindly—doing so would destroy the spaces inside actual text data—it must read the JSON file character by character from beginning to end, keeping track of its current "state."

The Finite State Machine Logic

The minifier typically operates using three primary states: OUTSIDE_STRING, INSIDE_STRING, and ESCAPE_CHARACTER.

The machine starts in the OUTSIDE_STRING state. It reads the first character. If the character is a structural symbol (like {, }, [, ], :, or ,), it outputs the character. If the character is one of the four whitespace characters, it simply ignores it and moves on, effectively deleting it.
If the machine encounters a double quote ("), it outputs the quote and immediately switches its state to INSIDE_STRING.
While in the INSIDE_STRING state, the machine outputs every single character it sees exactly as is, including all spaces and tabs.
If it encounters a backslash (\) while inside a string, it switches to the ESCAPE_CHARACTER state, outputs the backslash, outputs the very next character (regardless of what it is), and then reverts to INSIDE_STRING. This prevents an escaped quote (\") from tricking the machine into thinking the string has ended.
When it encounters an unescaped double quote, it outputs it and switches back to OUTSIDE_STRING.

A Complete Worked Example

Let us look at a mathematical example of minification savings. Consider the following formatted JSON payload representing a user profile:

{
  "id": 1048576,
  "name": "Jane Smith",
  "roles": [
    "admin",
    "user"
  ]
}

Step 1: Calculate the original size. Counting every character, including the spaces used for indentation and the hidden carriage return/line feed characters at the end of each line, this formatted string contains exactly 85 bytes (assuming standard UTF-8 encoding where 1 ASCII character = 1 byte).

Step 2: Apply the Finite State Machine. The minifier strips all line breaks and indentation spaces, but preserves the space between "Jane" and "Smith" because it is inside the INSIDE_STRING state. The resulting string is: {"id":1048576,"name":"Jane Smith","roles":["admin","user"]}.

Step 3: Calculate the minified size. Counting the characters in the new, single-line string, we find it contains exactly 58 bytes.

Step 4: Calculate the savings. We use the standard data reduction formula: Savings Percentage = ((Original Size - Minified Size) / Original Size) * 100. Plugging in our numbers: ((85 - 58) / 85) * 100 = (27 / 85) * 100 = 31.76%. By simply removing unnecessary formatting, we have reduced the payload size by nearly 32%.

Types, Variations, and Methods

While the end goal of JSON minification is always the same—a dense, unformatted string—the software engineering methods used to achieve this goal vary significantly based on performance requirements and safety constraints. Developers must choose between different types of minifiers depending on their specific use case.

Regular Expression (Regex) Stripping

The most rudimentary form of minification utilizes Regular Expressions to identify and replace whitespace. A common regex pattern might look for spaces that are not enclosed in quotes. This method is incredibly fast to execute and requires very little memory overhead. However, it is fundamentally brittle. Because regular expressions cannot easily maintain state or understand deep hierarchical nesting, a regex-based minifier is highly susceptible to edge cases involving complex escaped characters or nested stringified JSON. Regex stripping is generally discouraged in enterprise production environments due to its high risk of corrupting data.

Lexical Tokenization (Streaming Minifiers)

A more robust approach is the lexical tokenizer, which implements the Finite State Machine described in the previous section. Instead of loading the entire JSON document into memory at once, a streaming tokenizer reads the file in small chunks (e.g., 4 kilobytes at a time), processes the characters, and immediately streams the minified output to the destination. This variation is paramount when dealing with massive JSON files. If a developer needs to minify a 5-gigabyte JSON database export, loading the whole file into RAM using a standard parser would crash the server with an Out Of Memory (OOM) error. A streaming tokenizer can minify that 5-gigabyte file using less than 10 megabytes of RAM.

Abstract Syntax Tree (AST) Parsers

The most secure, but computationally expensive, method is AST parsing. In this method, the software fully parses the JSON text into native objects (e.g., using JSON.parse() in JavaScript), and then immediately serializes those objects back into text without any formatting arguments (e.g., using JSON.stringify()). The massive advantage here is guaranteed validity; if the original JSON has a syntax error, the parser will throw a loud error immediately, preventing the system from passing along corrupted data. The trade-off is speed and memory. Parsing a 100-megabyte JSON file into an AST can consume 300 to 500 megabytes of RAM and take several seconds, making it unsuitable for high-throughput, real-time API responses.

Real-World Examples and Applications

To fully grasp the magnitude of JSON minification, we must examine concrete, real-world engineering scenarios where the mathematics of data transfer dictate architectural decisions. The impact of minification is most pronounced in high-volume, low-bandwidth, and cost-sensitive environments.

The E-Commerce Product Catalog

Consider a global e-commerce platform that serves a mobile application. When a user opens the app, it fetches a JSON payload containing the user's customized product recommendations. A beautifully formatted JSON response containing 1,000 products might weigh exactly 2,500 kilobytes (2.5 MB). Through strict JSON minification, the engineering team strips out the heavy indentation, reducing the payload to 1,800 kilobytes (1.8 MB)—a savings of 700 KB per request.

If this application has 500,000 daily active users, each opening the app an average of 4 times per day, the API receives 2,000,000 requests daily. By saving 700 KB per request, the company saves 1,400 gigabytes (1.4 terabytes) of data transfer every single day. At a standard AWS CloudFront data egress rate of $0.085 per gigabyte, this simple minification saves the company $119 per day, or roughly $43,435 per year in raw bandwidth costs, requiring zero changes to the actual data structure.

Internet of Things (IoT) Sensor Networks

In the realm of IoT, devices often operate on constrained cellular networks (like NB-IoT or LTE-M) where bandwidth is severely limited and devices run on battery power. Imagine an agricultural sensor network with 50,000 soil moisture monitors placed across a massive farm. Every 15 minutes, each sensor transmits a JSON payload containing temperature, humidity, and battery life data to a central server.

Because these sensors transmit data over a cellular modem, every extra byte requires the modem to stay powered on for milliseconds longer, draining the battery. A formatted JSON payload might be 120 bytes, while a minified version is only 75 bytes. Over a 5-year lifespan, transmitting 96 times a day, that 45-byte difference equates to 7.8 megabytes of saved transmission per device. For the entire 50,000-device network, that is 390 gigabytes of data not transmitted over expensive cellular data plans, and months of extended battery life across the hardware fleet, drastically reducing physical maintenance costs.

Compression vs. Minification: The GZIP Factor

One of the most critical concepts for any software engineer to master is the distinct difference between JSON minification and network-level compression algorithms like GZIP or Brotli. These two processes are frequently confused, but they solve different problems using completely different mathematical principles, and they are designed to be used together.

Minification is a domain-specific process. It understands the grammar of JSON and safely removes characters that are structurally useless (whitespace). It does not alter the actual data. If the word "category" appears 500 times in your JSON file, minification will leave the word "category" intact 500 times.

Compression algorithms like GZIP, on the other hand, are domain-agnostic. GZIP treats the JSON file as a generic stream of bytes. It uses an algorithm called DEFLATE, which combines LZ77 (a dictionary-based compression) and Huffman coding. When GZIP sees the word "category" 500 times, it replaces the 2nd through 500th instances with a tiny mathematical pointer back to the first instance. GZIP can routinely compress a 1-megabyte JSON file down to 150 kilobytes.

Because GZIP is so incredibly powerful, a common misconception is that minification is no longer necessary. If GZIP compresses everything anyway, why bother stripping spaces? The mathematical truth is that GZIP compresses entropy (randomness and variation). While GZIP is excellent at compressing repeated spaces, it still requires bytes to store the pointers and dictionary entries for those spaces. When you minify JSON before passing it to GZIP, you are feeding the compression algorithm a smaller, denser file with less entropy. Industry benchmarks consistently show that a GZIP-compressed minified JSON file will be 5% to 10% smaller than a GZIP-compressed formatted JSON file. In high-scale environments, combining both techniques is the non-negotiable standard.

Common Mistakes and Misconceptions

Despite its conceptual simplicity, implementing JSON minification in production systems is fraught with potential pitfalls. Beginners and experienced developers alike frequently fall victim to several well-documented mistakes that can lead to catastrophic data corruption or system outages.

Modifying Keys or Values

The most devastating mistake developers make is using aggressive minification tools that attempt to shorten JSON keys to save space. For instance, a tool might attempt to change the key "user_first_name": "John" to "a": "John". While this drastically reduces file size, it fundamentally alters the semantic meaning of the data. This is no longer minification; it is data obfuscation or structural transformation. If the client application is expecting the key "user_first_name", the application will crash when it receives "a". True JSON minification must never alter the characters inside the quotation marks of keys or values.

The "Pretty Print" Production Leak

A remarkably common error occurs in the backend serialization configuration. Most modern programming frameworks (like Spring Boot in Java, or Express in Node.js) offer a "pretty-print" flag for JSON serialization, designed to help developers debug APIs during local development. A frequent mistake is accidentally deploying the application to production with this flag left enabled. Because the system works perfectly fine functionally, this mistake goes unnoticed in automated testing. The only symptom is a silent, massive spike in cloud bandwidth costs and degraded client performance.

Ignoring Whitespace Inside Strings

Developers who attempt to write their own custom regex-based minifiers often fail to account for the sanctity of strings. They write a script that globally deletes all line breaks (\n) in a file. However, if a user has submitted a multi-line comment in a text box, that JSON payload might contain a string like "comment": "Line 1\nLine 2". A naive global replace will delete the \n, merging the text into "Line 1Line 2". This permanently destroys user data. Minification must strictly adhere to the Finite State Machine rules previously outlined.

Best Practices and Expert Strategies

To harness the full benefits of JSON minification without exposing a system to risk, industry experts rely on a set of standardized best practices. These strategies ensure that data remains safe, systems remain performant, and bandwidth is optimized.

Build-Time vs. Run-Time Minification

Experts separate minification into two distinct architectural categories: build-time and run-time. If an application serves static JSON files (such as configuration files, localization dictionaries, or predefined geographic data), these files should always be minified at build-time. During the Continuous Integration/Continuous Deployment (CI/CD) pipeline, tools like Webpack or Rollup should parse the formatted source code, generate minified JSON artifacts, and deploy only the minified versions to the production servers or Content Delivery Networks (CDNs). This requires zero CPU cycles on the server during actual user requests.

Conversely, dynamic data pulled from a database (like a user's shopping cart) must be minified at run-time. In this scenario, the best practice is to configure the backend serialization library (such as Jackson for Java, or encoding/json in Go) to output minified JSON by default. These native libraries are heavily optimized, written in low-level languages, and can serialize data into minified strings directly from memory with almost zero performance penalty.

Caching Minified Responses

When dealing with dynamic data that is requested frequently but changes infrequently (such as the top 100 high scores on a gaming leaderboard), experts utilize caching layers like Redis or Memcached. The critical best practice here is to cache the minified version of the JSON string, not the raw object or the formatted string. By caching the final minified string, the web server can retrieve the data from memory and blast it directly to the network socket without spending any CPU cycles on serialization or minification.

Content Negotiation and Debugging

Because production APIs should always return minified JSON, debugging issues in production can become difficult for developers who need to read the responses. Experts solve this by implementing content negotiation or query parameter overrides. A production API will return strict, minified JSON by default. However, if an authorized developer appends a specific query parameter, such as ?pretty=true, the server will bypass the minifier and return beautifully formatted JSON. This provides the best of both worlds: maximum efficiency for machines, and on-demand readability for human engineers.

Edge Cases, Limitations, and Pitfalls

While JSON minification is universally recommended, it is not a magic bullet, and there are specific edge cases where standard minification techniques break down or introduce unexpected bottlenecks.

The Memory Overhead of Massive Files

As mentioned in the variations section, attempting to minify exceptionally large JSON files—such as a 10-gigabyte database dump—using standard AST parsing will almost certainly cause a system crash. The limitation here is RAM. When a parser loads a JSON file into an AST, the resulting in-memory tree structure is typically 3 to 5 times larger than the raw text file. A 10GB file will require 30GB to 50GB of RAM to parse. In these edge cases, developers must abandon standard parsers and utilize dedicated streaming minifiers that process the file sequentially, ensuring memory consumption remains flat regardless of file size.

Deeply Nested Structures and Stack Overflows

JSON allows for infinite nesting of objects and arrays. A maliciously crafted JSON file, or a file generated by a recursive data structure error, might contain 10,000 layers of nested arrays (e.g., [[[[[[...]]]]]]). Many AST-based minifiers use recursive functions to traverse the tree structure. When faced with extreme nesting, these recursive functions will exceed the maximum call stack size of the programming language, resulting in a Stack Overflow error and crashing the application. Robust minifiers must implement depth-limits or use iterative traversal algorithms to protect against this pitfall.

Unicode and Escaped Characters

JSON natively supports Unicode, allowing for characters from any human language, as well as emojis. However, the JSON specification allows these characters to be represented in two ways: as raw UTF-8 bytes, or as escaped Unicode sequences (e.g., \u263A for a smiley face ☺). A naive minifier might attempt to "optimize" the file by converting escaped sequences into raw bytes to save space (since \u263A is 6 bytes, but the raw UTF-8 character is 3 bytes). While technically smaller, this is a dangerous pitfall. If the receiving system does not properly support UTF-8 encoding, the raw bytes will be corrupted into gibberish. A strict minifier should only remove whitespace and never alter character encodings.

Industry Standards and Benchmarks

In professional software engineering, decisions are driven by metrics and established benchmarks. The industry has established clear expectations for JSON payload optimization and API performance.

Typical Size Reductions

Across the industry, the baseline expectation for JSON minification is a size reduction of 10% to 20% for standard API payloads, and up to 40% for highly formatted, deeply nested configuration files. If an engineering team implements minification and sees less than a 5% reduction, it typically indicates that the original JSON was already partially optimized or lacked significant indentation.

API Response Time SLAs

Modern web architectures are governed by Service Level Agreements (SLAs) regarding response times. A widely accepted industry standard is that an internal microservice API should respond in under 50 milliseconds, and a public-facing API should respond in under 200 milliseconds. Because network latency is directly tied to payload size, failing to minify JSON can easily push an API over these thresholds. For a user on a standard 4G mobile network (with an average throughput of 15 Mbps), transmitting an unminified 5-megabyte JSON file takes roughly 2.6 seconds. Minifying that file down to 3.5 megabytes reduces the transfer time to 1.8 seconds—shaving nearly a full second off the user's wait time and keeping the application within acceptable performance bounds.

The RFC 8259 Standard

The absolute gold standard for JSON validity is the Internet Engineering Task Force (IETF) RFC 8259, published in December 2017. Any tool claiming to be a professional JSON minifier must strictly adhere to this document. The RFC clearly defines that whitespace is allowed before or after any of the six structural characters ([, ], {, }, :, ,). A compliant minifier guarantees that the output string will be successfully parsed by any RFC 8259 compliant deserializer on the planet, ensuring universal interoperability between entirely different programming languages and hardware architectures.

Comparisons with Alternatives

While JSON is the undisputed king of web APIs, it is fundamentally a text-based format. Even when perfectly minified and heavily GZIP-compressed, JSON retains a certain amount of inherent bloat because it must include structural characters (quotes, braces, colons) and represent all numbers as text strings (e.g., the number 1,000,000 takes 7 bytes in JSON, but only 4 bytes as a standard binary integer). For ultimate optimization, engineers must compare minified JSON against alternative binary serialization formats.

JSON vs. Protocol Buffers (Protobuf)

Protocol Buffers, developed by Google, is a binary serialization format. Unlike JSON, which includes the keys (e.g., "first_name") in every single payload, Protobuf relies on a pre-defined schema. The payload only contains the raw data and a tiny numeric tag indicating which field it belongs to. A minified JSON payload weighing 1,000 bytes can often be represented in Protobuf using just 300 bytes. Furthermore, parsing binary Protobuf is significantly faster than parsing text-based JSON. However, the trade-off is developer experience; Protobuf is completely unreadable to humans without the schema and specialized tooling, whereas minified JSON can still be easily formatted and read in a browser.

JSON vs. MessagePack and BSON

MessagePack and BSON (Binary JSON, popularized by MongoDB) are binary formats that, unlike Protobuf, do not require a pre-defined schema. They maintain the flexible, key-value structure of JSON but encode the data types and lengths into binary headers. This makes them faster for computers to parse than text JSON. However, in terms of sheer file size, MessagePack and BSON are often very similar in size to a strictly minified JSON file, and in some cases, BSON can actually be larger due to its length prefixes. When comparing these, minified JSON often wins for web APIs due to its native support in all web browsers, while BSON wins for database storage where rapid querying of nested data is required.

Ultimately, JSON minification is the bridge that allows developers to retain the immense flexibility, ubiquity, and schema-less nature of JSON, while mitigating its primary weakness: text-based bloat. Unless an application is operating at the extreme bleeding edge of high-frequency trading or massive scale internal microservices (where Protobuf is warranted), strictly minified and GZIP-compressed JSON remains the industry standard for optimal data transfer.

Frequently Asked Questions

Does minifying JSON change the actual data or values inside the file? No, true JSON minification never alters the semantic data. It strictly removes structural whitespace—spaces, tabs, and line breaks—that exist outside of string values. If you have a key named "user name" with a value of "John Doe", the space between "user" and "name", and the space between "John" and "Doe", are considered data and will be perfectly preserved. Only the spaces used for indentation and formatting are deleted.

Why should I minify JSON if my server already uses GZIP compression? While GZIP is incredibly powerful at compressing repetitive text, it relies on finding patterns and entropy in the byte stream. Whitespace formatting introduces unnecessary entropy into the file. By minifying the JSON before applying GZIP, you provide the compression algorithm with a smaller, denser baseline file. Industry benchmarks prove that a minified, GZIP-compressed file is consistently 5% to 10% smaller than a formatted, GZIP-compressed file, which translates to massive bandwidth savings at scale.

Can a JSON minifier break my application? Yes, if a poorly written minifier is used. The most common cause of breakage is using naive Regular Expressions that accidentally delete spaces inside string values, or that fail to properly handle escaped quotation marks (\"). If a minifier corrupts the syntax, the receiving application will throw a parsing error and crash. This is why it is critical to use robust, RFC 8259-compliant minifiers that utilize proper lexical tokenization or Abstract Syntax Tree parsing.

How do I read or debug a minified JSON file? Because minified JSON is a single, dense block of text, it is unreadable to the human eye. To debug it, you must reverse the process using a JSON formatter or "beautifier." Every modern Integrated Development Environment (IDE) like VS Code, and every modern web browser's developer tools, has built-in functionality to instantly format minified JSON back into a readable, indented structure. The data remains exactly the same; only the visual presentation changes.

Is it better to minify JSON at build-time or run-time? It depends entirely on the source of the data. For static JSON files, such as configuration documents or translation files bundled with a frontend application, you should always minify at build-time using your CI/CD pipeline to save server CPU cycles. For dynamic data generated on the fly, such as database query results returned by an API, you must minify at run-time by configuring your backend framework's serialization library to output unformatted JSON strings.

What is the maximum file size a JSON minifier can handle? The maximum file size depends on the specific architecture of the minifier tool. Tools that parse the JSON into an Abstract Syntax Tree (AST) are limited by system RAM and will typically crash on files larger than a few hundred megabytes. However, streaming minifiers, which read and process the file in tiny sequential chunks (using a Finite State Machine), have virtually no size limit. A streaming minifier can easily process a 50-gigabyte JSON file using only a few megabytes of memory.