How to test a PAC file (online, with pactester, and in the browser)

Published 6 October 2026

Testing a PAC file means asking FindProxyForURL the questions your users will ask, which URLs go where, in the engines your users actually run. Here are three ways to do it, from quickest to most realistic.

1. Online: test in several engines at once

The quickest check is an online PAC file tester. On findproxyforurl.net/check/:

Paste the file, or open it with Load file….
Enter the URLs you care about, one per line.
Press Check.

For every URL you get the result in each engine profile (Chromium, Firefox and pacparser), the line that decided it and the places where the engines disagree. The tester also runs probe URLs built from the domains in your file, and it rates the file against the rule catalogue. The file is evaluated in your browser, and only anonymised facts are sent for the rating (methodology).

2. Command line: pactester

pactester is the command-line tool of the pacparser library:

pactester -p proxy.pac -u http://www.example.com/
pactester -p proxy.pac -u https://intranet.corp.example/ -c 10.1.2.3

-p names the PAC file, -u the URL, and -c sets the client IP address that myIpAddress() returns (source: doc, pactester manual, checked 2026-10-06). It is ideal for scripts and CI: keep a list of URLs with the expected answers and fail the build when one changes.

Keep its limits in mind. pactester is one engine, and browsers behave differently from it. It passes the full URL to the script, while Chrome and Firefox remove the path and query of https:// URLs. It also does not lower-case host, and it has real DNS lookups (source: code, verified 2026-10-04; engine differences). A file that passes in pactester can still route differently in Chrome.

3. In the browser: the final word

For the clients you actually deploy to, test there too:

Chrome / Edge: start a test profile with --proxy-pac-url=https://pac.corp.example/proxy.pac. Use chrome://net-export to record which proxy was chosen.
Firefox: set network.proxy.type to 2 and network.proxy.autoconfig_url to the PAC URL in a test profile.

The debugging guide has the details.

Which URLs to test

A test is only as good as its URLs. For each rule in the file, test one URL that should match and one that should not. Then add the cases that break PAC files in practice:

Test URL	What it catches
`http://evilcorp.example/` when the file trusts `corp.example`	missing leading dot (PAC-X003)
`http://www.example.net/?r=partner.example.com`	substring match on `url` (PAC-C001)
`http://corp.example.attacker.test/`	trailing `*` in a host pattern (PAC-X002)
`http://10.1.2.3/` and `http://192.168.1.10/`	private ranges, IP literals
`http://intranet/`	plain host names
a URL that matches no rule	the default route exists (PAC-X001)

The online tester generates most of these probes for you from the domains in your file.

What “passing” means

Every URL returns a string in every engine; an exception or undefined means a direct connection in browsers.
The default route is the last statement, and it is commented.
No DNS functions run for ordinary requests (DNS in PAC files).
All engines agree, or you know why they do not.

That is also what the A+ grade in the tester requires.

Frequently asked questions

What is the fastest way to test a PAC file?

Paste it into an online PAC file tester such as findproxyforurl.net/check/, list a few URLs and press Check. You see the result per URL and engine, the line that decided it, and a list of problems.

How do I test a PAC file on the command line?

Install pacparser and run "pactester -p proxy.pac -u http://www.example.com/". Add -c with an IP address to set what myIpAddress() returns. pactester answers for the pacparser engine only.

Which URLs should I test?

One URL per rule in the file, plus the cases attackers use. Try look-alike domains (evilcorp.example for corp.example), trusted names inside a query string, IP addresses, plain host names and an https:// URL with a path.