Why Some JSON Responses Start with while(1); in JavaScript

By the end of this page, you will understand why some web applications prepend strings like while(1); to JSON responses, what JSON hijacking is, why this was historically important in JavaScript applications, and what safer modern alternatives are commonly used today.

The core idea

Prefixes like while(1); are a defensive trick added before JSON responses so the response is not directly executable as JavaScript.

This was mainly used to reduce the risk of a class of attacks often called JSON hijacking or cross-site script inclusion attacks.

Why this mattered

In older web applications, some endpoints returned sensitive data as raw JSON, often arrays or objects. If that JSON could be loaded in a <script> tag from another site, the browser might execute it as JavaScript in a way that exposed private data.

For example, if an authenticated user visited a malicious site, that site might try to load a private JSON endpoint from another domain:

<script src="https://example.com/private-data"></script>

If the response was valid executable JavaScript, the attacker could sometimes abuse that behavior.

What while(1); does

This prefix makes the response invalid as plain JSON and also useless when treated as a script:

while (1);
[{"secret":"data"}]

If a browser tries to execute that as JavaScript, it gets stuck in an infinite loop before reaching the data. That means the payload cannot be meaningfully consumed through script inclusion.

Think of the JSON response as a package being shipped.

• A normal JSON response is like a package with the contents immediately visible.
• A prefixed response adds a tamper seal on top.
• The official client knows how to remove the seal first.
• A browser blindly executing it as a script trips over the seal and cannot use the contents directly.

while(1); is an extreme kind of seal: if you try to "run" the package as code, you never get past the first line.

So the prefix is not meant to make the data impossible to read forever. It is meant to stop the browser from accidentally treating private data as executable script in the wrong context.

Basic pattern

A server may return something like this:

while (1);
{"name":"Alice","role":"admin"}

That is not valid JSON because of the extra prefix.

A trusted client can remove the prefix and then parse the rest.

Example in JavaScript

const responseText = 'while (1);{"name":"Alice","role":"admin"}';

const cleaned = responseText.replace(/^while \(1\);/, '');
const data = JSON.parse(cleaned);

console.log(data.name); // Alice

Another common prefix

const responseText = ")]}',\n{"ok":true}";
const cleaned = responseText.replace(/^\)\]\}',\n/, '');
const data = JSON.(cleaned);

Example response

while (1);
["red", "green", "blue"]

Client-side processing

const responseText = 'while (1);["red", "green", "blue"]';
const cleaned = responseText.replace(/^while \(1\);/, '');
const colors = JSON.parse(cleaned);

console.log(colors[1]);

Step by step

1. The server sends text

The client receives this exact string:

while (1);["red", "green", "blue"]

2. The prefix is removed

This line removes the anti-execution prefix:

const cleaned = responseText.replace(/^while \(1\);/, );

1. Private web app endpoints

Large JavaScript applications such as mail, calendar, and admin dashboards often had internal endpoints returning structured data. Prefixes were used so those endpoints could not be safely included as scripts from another origin.

2. Protecting authenticated GET responses

If a browser automatically sent cookies with a request, a malicious site might try to load a user's private data through a <script> tag. Prefixing the response reduced that risk.

3. Legacy AJAX applications

Before modern browser security features became standard, many applications used custom response formats and defensive prefixes as an extra layer of protection.

4. Internal APIs with custom clients

Some apps controlled both server and client code. That made it practical to add a prefix server-side and remove it client-side before parsing.

5. Defensive parsing conventions

Even today, some systems add a non-JSON prefix like )]}', to ensure the client explicitly recognizes and parses the payload rather than accidentally executing it.

Common patterns in real projects

Explicit response normalization

Developers often create a small utility that removes known prefixes before parsing:

function parseSafeJson(text) {
  const cleaned = text
    .replace(/^while \(1\);/, '')
    .replace(/^for \(;;\);/, '')
    .replace(/^\)\]\}',?\n/, '');

  return JSON.parse(cleaned);
}

This keeps the parsing logic in one place.

Guard clauses

A parser may first verify that the payload begins with an expected prefix or valid JSON token:

function parseGoogleStyleResponse(text) {
  if (text.startsWith('while (1);')) {
    text = text.slice('while (1);'.length);
  }

  return JSON.parse(text);
}

Validation before parsing

1. Treating prefixed JSON as normal JSON

This will fail because the response contains extra characters before the JSON.

Broken code:

const text = 'while (1);{"ok":true}';
JSON.parse(text); // Error

Fix:

const cleaned = text.replace(/^while \(1\);/, '');
JSON.parse(cleaned);

2. Using eval() to parse the response

Broken code:

const data = eval(text);

Why it is wrong:

• executes code instead of parsing data
• unsafe for untrusted input
• unnecessary in modern JavaScript

Fix:

const data = JSON.parse(cleaned);

3. Removing the prefix too loosely

If you do a generic replace, you may accidentally modify valid content later in the string.

Related approaches

Quick reference

What is while(1); before JSON?

A defensive prefix added before a JSON payload so the response is not directly executable as JavaScript.

Why was it used?

Mostly to reduce the risk of JSON hijacking or cross-site script inclusion attacks in older web apps.

What should a client do?

1. Remove the known prefix
2. Parse the remaining text with JSON.parse()

Example

const cleaned = text.replace(/^while \(1\);/, '');
const data = JSON.parse(cleaned);

Common prefixes

while (1);
for (;;);
)]}',
&&&START&&&

Do not do this

eval(text)

Important rule

A prefix is an extra defense, not a replacement for:

Why does while(1); stop the response from being used as a script?

Because it starts an infinite loop immediately, so the rest of the response is never usefully executed when treated as JavaScript.

Is while(1); valid JSON?

No. It makes the response invalid as raw JSON until the prefix is removed.

Was this mainly about stopping eval()?

Not primarily. It was mainly a defense against browsers loading private JSON endpoints as scripts from another site.

Why could a normal client still use the response?

Because the intended client knows to remove the prefix first and then parse the remaining JSON.

What is JSON hijacking?

It is a class of attacks where a malicious site tries to exploit how browsers handle script loading to access sensitive JSON from another origin.

Why do some services use )]}', instead?

It serves a similar purpose: making the response invalid or non-executable until the client explicitly strips the prefix.

Is this still needed in modern APIs?

Usually not as a primary defense. Modern APIs more commonly rely on CORS, CSRF protection, secure cookies, and token-based authentication.

Should I add while(1); to my own API?

Usually no, unless you are maintaining a legacy client/server contract. For new APIs, plain JSON plus proper security controls is typically better.

JSON

The underlying data format being protected and parsed.

JSON.parse()

The correct JavaScript method for turning JSON text into data.

eval()

Often mentioned because it can execute response text, but it should not be used for parsing JSON.

Same-Origin Policy

Important background for understanding why cross-site script loading was a concern.

CORS

Modern browser mechanism for controlling which origins can read responses.

CSRF

Another web security issue often discussed alongside authenticated browser requests.

XSSI

Cross-site script inclusion is closely related to why non-JSON prefixes were added.

Content-Type headers

Help browsers and clients interpret responses correctly.

Authentication and cookies

Relevant because these attacks often depended on the browser sending credentials automatically.