Methodology

How the PAC file tester gets from your proxy.pac to a list of findings and a grade, and how to judge how far to trust each part.

1. Running the file: engine profiles

Browsers do not share one PAC implementation. The tester models three of them as engine profiles: Chromium (Chrome, Edge, Brave, Opera, Vivaldi, Electron), Firefox and pacparser (the library behind pactester). Each profile has version ranges.

  • Where the licence allows, a profile runs the engine’s own helper library, copied verbatim from the upstream source at a pinned commit. Otherwise the library is emulated.
  • On top of that, the profile models the engine’s documented differences: how much of the URL the script sees, whether host is lower-cased, which functions exist, how DNS behaves and what happens on an exception or a missing return value. The differences table lists them side by side.
  • The PAC runs in a sandboxed worker on a separate origin, with a time limit. myIpAddress(), DNS answers and the date and time come from the values you set, so results are reproducible.

Each of your test URLs runs in each selected profile. The tester adds probe URLs built from the domains in your file, such as look-alike domains, query strings that contain a trusted name, and IP literals, because the dangerous cases are usually the ones nobody thought to test.

Profiles are models, not browsers. The pacparser profile is compared against the real pacparser library in automated parity tests. Browser behaviour is being confirmed in a lab with real Chrome, Edge and Firefox builds. Where a lab result exists, the claim is marked lab.

2. Findings: the rule catalogue

Every check is a public rule with an id, a category, a severity, an explanation, a bad and a good example and, where engines differ, per-engine notes. Rules belong to six categories: errors and robustness, security and fail-safety, correctness, compatibility across engines, performance, and best practice. Delivery (how the file is served) is graded separately when you paste the response headers.

Most rules are static: they read the code. Some depend on evaluation results, for example a function that returns nothing for some URL, or engines that disagree on the same input.

3. The grade

Each category starts at 100 and loses points for every finding, more for higher severities and for repeated hits. The weighted result gives a letter from A to F, modelled on how TLS test services grade servers. Serious findings, such as a file that does not load or a high-severity security bypass, limit the letter however good the rest is.

A+ requires an A with no warnings at all, a commented default route and the same result in every engine profile. A- is an A with at least one warning. The basic checks run in your browser; the full rating is computed on the server, so the rules can be improved without shipping new code.

4. Evidence: where every engine claim comes from

Each statement about engine behaviour carries a source type and a date:

SourceMeaning
coderead in the engine’s source code at a pinned commit or tag
docvendor documentation or release notes
labobserved in a lab run against the real engine
expertpractitioner knowledge, not yet verified (shown as unverified)

New engine releases are watched automatically. When PAC-related source files change, the affected claims are reviewed.

5. Privacy: what leaves your browser

  • The PAC file is parsed and evaluated in your browser.
  • For the rating, the browser sends anonymised facts about the code: which functions it calls with which patterns and what it returns. Comments are removed, and your organisation’s domains and IP addresses are replaced. You can see and edit the replacement table on the tester page.
  • The original file is never sent or stored.
  • The optional full report shows you the anonymised file before anything is uploaded, and you can change it or cancel.
  • The site sets no cookies and loads no analytics or third-party scripts.

Limits

A model can be wrong where the real engine has undocumented behaviour, and other PAC consumers exist: WinHTTP-based Windows services, macOS and iOS, Android and appliances. Always confirm critical changes in the client you actually deploy to. The tester’s “Target WinHTTP / ES5 engines” setting flags modern JavaScript syntax that older engines reject.