---
sourceDocument: Brazil API Reference
sourceDocumentLink: https://www.servicenow.com/docs/r/api-reference

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil API Reference

ft:clusterId :

    - crapiref

bundleId :

    - crapiref

workflow :

    - Creator


---

# Considerations for switching JavaScript modes

# Considerations for switching JavaScript modes {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Considerations for switching JavaScript modes

Switching JavaScript modes in ServiceNow applications or scripts can significantly alter script behavior.
This guide compares behavior differences across three JavaScript modes: Compatibility Mode (pre-ES5), ES5 Standards Mode, and ECMAScript 2021 (ES12).
Understanding these differences helps customers anticipate changes, avoid unexpected issues, and troubleshoot effectively after transitioning between modes.
Show full answer Show less  

## Key Behavioral Differences Across JavaScript Modes

* **Arguments Object:**
  * Compatibility Mode: Arguments object exists without strict mode, allowing parameter modifications to reflect on arguments.
  * ES5 and ES12: Arguments do not reflect parameter modifications in strict mode and can throw errors.
* **Boolean Overrides:**
  * Compatibility Mode: Primitive Booleans can be overridden, possibly causing unexpected behavior.
  * ES5 and ES12: Primitive Booleans are more protected; strict mode helps prevent unsafe assignments. Use conditional expressions to handle Boolean objects safely.
* **Syntax Errors:**
  * Compatibility Mode: Syntax errors throw runtime exceptions with inconsistent handling.
  * ES5: More consistent error handling, especially in strict mode.
  * ES12: Further improved robustness and clearer error messages.
* **Increment and Decrement Operators:**
  * Compatibility Mode: Allowed but could behave unexpectedly with complex expressions.
  * ES5 and ES12: Improved clarity and stricter rules in some contexts (e.g., `const`).
* **Line Continuations:**
  * Compatibility Mode and ES5: Allowed with backslash but discouraged for readability.
  * ES12: Same handling as ES5, with template literals offering better multiline alternatives.
* **Missing Semicolons:**
  * Compatibility Mode: Automatic semicolon insertion (ASI) could cause unexpected results.
  * ES5 and ES12: Missing semicolons throw syntax errors, promoting explicit semicolon use.
* **Calling Non-existent Functions:**
  * Compatibility Mode: Throws `ReferenceError`.
  * ES5: Throws `TypeError` if a non-function is called.
  * ES12: Throws `EcmaError` when non-existent functions or properties are accessed.
* **Accessing Non-existent Properties:**
  * All modes: Returns `undefined` without throwing errors.
* **Numeric Literals:**
  * Compatibility Mode: Supports basic decimal and hexadecimal.
  * ES5: Introduces stricter parsing and improved handling.
  * ES12: Adds support for binary, octal, and BigInt literals.
* **Reserved Keywords as Properties:**
  * Compatibility and ES5: Reserved keywords cannot be used as property names.
  * ES12: Reserved keywords can be used as property names without errors.
* **Use of `let` and `yield` Identifiers:**
  * Compatibility Mode: `let` and `yield` are not keywords and usable as identifiers.
  * ES5: `let` introduced as keyword; `yield` reserved in strict mode.
  * ES12: Both are keywords; using them as identifiers causes syntax errors.

## Practical Guidance for ServiceNow Customers

Before switching JavaScript modes, thoroughly review the behavior changes to understand their impact on existing scripts. This is especially crucial for scripts that rely on lenient behaviors like automatic semicolon insertion or flexible argument handling. Switching to newer modes like ES5 or ES12 enhances script predictability, error handling, and access to modern language features but may require script refactoring to comply with stricter syntax and semantics.

Expect clearer error messages and better debugging support after switching, but also anticipate possible breaking changes if legacy code depends on pre-ES5 behaviors. Use explicit semicolons, avoid overriding primitives, and adopt modern syntax practices to align with ES5 and ES12 standards.  
Switching the JavaScript mode for an application or script might change the behavior of
existing scripts. Review some examples of behavior changes before switching JavaScript modes or to
troubleshoot any issues that you experience after switching.

For more information about each JavaScript mode, see [JavaScript modes](https://www.servicenow.com/docs/u5NMvXvgCCfS0Nwm14sCgg "JavaScript mode is a design and runtime setting for custom applications and scripts. To support existing server-side scripts and new scripts developed to the ECMAScript 2021 standard, the JavaScript engine has three modes: ECMAScript 2021 (ES12), ES5 Standards, and Compatibility.") and [JavaScript engine feature support](https://www.servicenow.com/docs/feDR40ow0ca7mNVjzj_tOg "Compare ECMAScript features between the ECMAScript 2021 (ES12) and ES5 Standards JavaScript modes in Brazil. Both modes support a subset of ECMAScript features.").

This table highlights how JavaScript behavior has evolved from the lenient and error-prone
pre-ES5 environment, to the stricter and more predictable ES5, and lastly the more feature-rich
environment of ES12 (ECMAScript 2021).  
{#considerations-switching-javascript-mode__table_r4b_j4r_fcc__entry__4}

| Feature | Compatibility Mode | ES5 Standards Mode | ECMAScript 2021 (ES12) |
|-|-|-|-|
| Arguments object | The `arguments` object exists, but there's no `strict mode`, so modifications reflect on `arguments`. Prints: *** Script: [object Arguments] *** Script: [object Arguments] *** Script: [object Arguments] *** Script: 123 {#considerations-switching-javascript-mode__codeblock_xph_2vz_pcc} | In strict mode, the arguments object doesn't reflect parameter modifications and throws an error. Prints: sn_es5: 123 sn_es5: undefined sn_es5: [object Arguments] sn_es5: 123 {#considerations-switching-javascript-mode__codeblock_yph_2vz_pcc} | The same as ES5. |
| Boolean overrides | Primitive Booleans (`true`, `false`) can be overridden, causing unexpected behavior. | Primitive Booleans are more protected, though still can be overridden when assigned to variables. | The same as ES5, but strict mode helps prevent some assignments. The conditional expression should be written in this form: (cond_expr instanceof Boolean ? cond_expr.valueOf() : cond_expr). {#considerations-switching-javascript-mode__codeblock_zph_2vz_pcc} |
| Exception for syntax errors | Syntax errors throw exceptions at runtime. Error handling is inconsistent. Example: Javascript compiler exception: unterminated string literal (null.null.script; line 1) in: var b = ' {#considerations-switching-javascript-mode__codeblock_aqh_2vz_pcc} | More consistent syntax error handling, especially in strict mode. Example: Evaluator: com.glide.script.RhinoEcmaError: unterminated string literal script : Line(1) column(9) ==>   1: var b = ' {#considerations-switching-javascript-mode__codeblock_bqh_2vz_pcc} | The same as ES5, but with more robust handling and clearer error messages in updated engines. Example: SyntaxError: Unterminated string constant at line 1 ==>   1: var b = ' {#considerations-switching-javascript-mode__codeblock_cqh_2vz_pcc} |
| Increment and decrement | Allowed on variables but could behave unexpectedly with complex expressions. Prints: *** Script: c: 1 *** Script: gr.related_incidents: 1 *** Script: 2 *** Script: 3 {#considerations-switching-javascript-mode__codeblock_dqh_2vz_pcc} | Improved clarity, but still allowed on variables (`var`, `let`, `const`). Prints: sn_es5: c: 0 sn_es5: gr.related_incidents: 1 sn_es5: 1 sn_es5: 2 {#considerations-switching-javascript-mode__codeblock_eqh_2vz_pcc} | The same as ES5, with stricter rules in some contexts (for example, `const`). |
| Line continuations | Allowed with a backslash (`\`) but discouraged due to readability issues. In this example, all three functions are called. var expr = doFoo();  // do foo doBar();  // do bar finish();   // all done eval(expr); {#considerations-switching-javascript-mode__codeblock_fqh_2vz_pcc} | Same as Compatibility mode; no change in handling line continuations. In the previous example, ES5 only calls the first function and treats everything after the first comment including the newline as comment until the expression end. | The same as ES5, but template literals provide a more readable alternative. |
| Missing semicolons | Automatic semicolon insertion (ASI) often led to unexpected behavior. | Throws a syntax error when a semicolon is missing. | The same as ES5. Updated practices encourage explicit semicolons. |
| Non-existent functions | Calling a non-existent function throws a `ReferenceError`. | Throws a `TypeError` if a non-function is called. | Throws an EcmaError when a non-existent function is called or a property is referenced. |
| Non-existent properties | Accessing a non-existent property returns `undefined`; no error thrown. | Same as pre-ES5. | The same as Compatibility mode and ES5 Standards mode. |
| Numeric literals | Basic decimal and hexadecimal literals. | Introduced stricter parsing rules and better handling of numeric literals. | Added binary (`0b`), octal (`0o`), and BigInt literals (`123n`). |
| Reserved keyword as property | Using reserved keywords isn't possible. | Reserved keywords can be used as property names without error, for example, `obj.for`. Prints the object when returned. | The same as ES5. |
| Treat let and yield as keywords | `let` and `yield` aren't keywords and can be used as identifiers only. | `let` is introduced as a keyword. `yield` is reserved in strict mode. | Both are keywords. Using them as identifiers throws syntax errors. |
[Table 1. Behavioral differences in JavaScript modes]

{#considerations-switching-javascript-mode__table_r4b_j4r_fcc}