PAC-E013 · byte-order-mark

File starts with a UTF-8 byte order mark

medium · Errors and robustness

The first three bytes are a UTF-8 BOM, typically written by Windows editors. Modern browsers strip it; older or embedded engines may fail to parse the file.

Why it matters

A BOM is not part of JavaScript syntax. V8 and SpiderMonkey skip it, so Chromium and Firefox are unaffected. Reports exist of WinHTTP-based clients and embedded engines treating it as an invalid token, which turns the whole file into a parse error (silent DIRECT). It is also a sign that the file was edited with a tool that may have introduced other non-ASCII characters (PAC-E014, PAC-E015). A PAC file should be plain 7-bit ASCII.

Draft: the WinHTTP behaviour is from field reports and needs a lab run.

How to fix

Save the file as UTF-8 without BOM (or plain ASCII); check with `hexdump -C file | head -1`.

Examples

Bad

// (the file begins with the invisible bytes EF BB BF before this comment)
function FindProxyForURL(url, host) {
  return "DIRECT";
}
Open bad example in checker

Good

function FindProxyForURL(url, host) {
  return "DIRECT";
}
Open good example in checker

Engine behaviour

EngineBehaviourSource
chromiumBOM is skipped by the parser.expert, unverified
winhttpReported to fail parsing; needs lab confirmation.expert, unverified

Source: code = read in the engine's source, doc = vendor documentation, lab = observed in a lab run, expert = practitioner knowledge, not yet verified.

Related rules

References