About ProxyBridge Profile Editor
ProxyBridge Profile Editor opens a .pbprofile file — the JSON document that holds ProxyBridge's proxy configurations and routing rules — in structured forms, and writes a validated file back out. It reads both field styles the format appears in, keeps rules pointed at real proxy entries, and produces the download locally.
A .pbprofile is a single JSON object with two arrays that matter: the proxy configurations and the routing rules. A rule carries a process match, a target host match, a target port match, a protocol and an action, and the rules are read from the top of the array downwards, so the first enabled rule that matches a connection decides it. The awkward part when editing the file by hand is the link between the two arrays: in the field style used by the macOS sample, a rule that proxies traffic does not write the word PROXY at all — the action field holds the proxy's own id, and a typo there produces a profile that parses as JSON and still routes nothing. This editor shows the action as a choice plus a proxy picker, and refuses to export a rule whose proxy is not in the list.
How to use this developer tool
- Upload the .pbprofile you already use, or start from a blank profile whose single rule is a DIRECT catch-all.
- Pick the export field style: macOS sample, which is the camelCase shape the desktop application exports, or cross-platform / CLI, which is the PascalCase shape with a version field.
- Set the profile name, the output file name and the application toggles. Which toggles survive depends on the style, so choose the style before you spend time on them.
- Add each proxy configuration with a name, SOCKS5 or HTTP, a host and a port, plus a username and password only when the upstream needs them.
- Add rules and order them with the arrows: process or bundle id, target hosts, target ports, protocol, then the action — PROXY with a chosen proxy, DIRECT, or BLOCK.
- Press validate and download .pbprofile. The export stops if a PROXY rule has no valid proxy behind it, or if a host is empty or a port is outside 1-65535.
Worked example: keeping LAN traffic off the proxy
The input is a profile exported by the desktop application in the macOS sample style, abbreviated to one proxy and one rule. Its catch-all rule proxies everything, including loopback and LAN destinations. The output is what the editor downloads after a DIRECT rule is added above it.
{
"name": "Work",
"runAtStartup": false,
"closeToMenuBar": true,
"trafficLoggingEnabled": true,
"proxyConfigs": [
{
"id": "6F2B0C7E-9A43-4E51-9B0D-1C5A7E8D2F10",
"name": "HK SOCKS5",
"type": "socks5",
"host": "proxy.example.com",
"port": 1080,
"username": "alice",
"password": "s3cret"
}
],
"proxyRules": [
{
"localId": "B1D9E6C4-77A8-4B30-A2F5-5E8C1D9046AB",
"name": "Default",
"enabled": true,
"processNames": "*",
"targetHosts": "*",
"targetPorts": "*",
"protocol": "BOTH",
"action": "6F2B0C7E-9A43-4E51-9B0D-1C5A7E8D2F10"
}
]
}{
"closeToMenuBar": true,
"name": "Work",
"proxyConfigs": [
{
"host": "proxy.example.com",
"id": "6F2B0C7E-9A43-4E51-9B0D-1C5A7E8D2F10",
"name": "HK SOCKS5",
"port": 1080,
"type": "socks5",
"username": "alice",
"password": "s3cret"
}
],
"proxyRules": [
{
"action": "DIRECT",
"enabled": true,
"localId": "0B7C4A11-3E5D-4F2A-8C61-9D0E2B4F7A33",
"name": "LAN direct",
"processNames": "*",
"protocol": "BOTH",
"targetHosts": "127.0.0.1; 192.168.*.*; *.local",
"targetPorts": "*"
},
{
"action": "6F2B0C7E-9A43-4E51-9B0D-1C5A7E8D2F10",
"enabled": true,
"localId": "B1D9E6C4-77A8-4B30-A2F5-5E8C1D9046AB",
"name": "Default",
"processNames": "*",
"protocol": "BOTH",
"targetHosts": "*",
"targetPorts": "*"
}
],
"runAtStartup": false,
"trafficLoggingEnabled": true
}Read the action fields. The new rule says DIRECT, while the original rule's action is the proxy's id rather than the word PROXY — that is how this field style records a proxy rule, and the editor displays it as action PROXY with that proxy selected. Key order changed because the file is regenerated rather than patched; no value other than the added rule was touched.
macOS sample style versus cross-platform / CLI style
The same profile is written with different key names depending on the export style. Uploading either one works: the style is detected from whether the document uses the camelCase proxyConfigs and proxyRules keys.
| What it is | macOS sample style | Cross-platform / CLI style |
|---|---|---|
| Proxy array | "proxyConfigs" | "ProxyConfigs" |
| Proxy identifier | "id", a UUID string | "Id", a number |
| Proxy type | "type": "socks5" or "http" | "Type": same two values |
| Port | "port": 1080, a number | "Port": "1080", a string |
| Credentials | "username" / "password", written only when one is set | "Username" / "Password", always written, empty when unused |
| Rule array | "proxyRules" | "ProxyRules" |
| Process match | "processNames" | "ProcessName" |
| Host and port match | "targetHosts" / "targetPorts" | "TargetHosts" / "TargetPorts" |
| Protocol | "protocol": TCP, UDP or BOTH | "Protocol": same three values |
| Enabled flag | "enabled" | "IsEnabled" |
| DIRECT and BLOCK | "action": "DIRECT" or "BLOCK" | "Action": "DIRECT" or "BLOCK" |
| PROXY action | "action" holds the proxy id instead of a keyword | "Action": "PROXY" plus a separate "ProxyConfigId" |
| Profile-level settings | name, closeToMenuBar, runAtStartup, trafficLoggingEnabled | Version, LocalhostViaProxy, IsTrafficLoggingEnabled |
| Rule name | "name", preserved | not written at all; names become Rule 1, Rule 2 on re-import |
Troubleshooting
Validation fails on a rule whose action is PROXY, although a proxy is clearly configured.
Why it happens The rule references a proxy id that is not in the proxy list. An uploaded file keeps that dangling reference, since the id in the action field is taken at face value.
Fix Open the rule and choose a proxy from the dropdown, or set the action to DIRECT. Also re-read your rules after deleting a proxy: every rule that used it is switched to DIRECT automatically, which silently un-proxies that traffic.
A per-application rule is ignored and everything goes the same way.
Why it happens A rule above it matches first. A rule with process, hosts and ports all set to * matches every connection, so nothing below it is ever reached.
Fix Move the specific rule above the general one with the arrows, and keep exactly one catch-all at the bottom. Remember that on macOS, UDP rules match mainly on the process and bundle-id fields, so a UDP rule keyed only on a hostname may not behave the way the TCP rule beside it does.
After switching to the cross-platform / CLI style, a rule's ProxyConfigId does not match any ProxyConfigs Id.
Why it happens That style numbers proxies, while proxies created in this editor carry UUID identifiers. When a UUID cannot be read as a number, the proxy entries are numbered 1, 2, 3 by position and the rule keeps the original identifier.
Fix Build cross-platform profiles from a file the application exported in that style, so the ids are already numeric. If you started from scratch, open the downloaded JSON and set each ProxyConfigId to the numeric Id of the proxy it should use.
The application does not list the downloaded file when you try to import it.
Why it happens The extension changed on the way to disk. Browsers sometimes append .json or .txt to a downloaded file, and a name typed without an extension is not what the import dialog filters for.
Fix The editor appends .pbprofile when the output name lacks it, so check the file on disk rather than the field. Rename it back to a single .pbprofile extension, and turn off any browser setting that rewrites downloaded file names.
Local services stop responding once the profile is applied.
Why it happens The catch-all PROXY rule also matches 127.0.0.1, your LAN range and internal hostnames, so a local development server is being dialled through the upstream.
Fix Put a DIRECT rule above the catch-all covering 127.0.0.1, ::1, your LAN prefix and internal suffixes. Note that the localhost-via-proxy toggle is only written in the cross-platform / CLI style; the macOS sample output does not carry it, so in that style the DIRECT rule is the mechanism.
When this tool is the right choice
- Writing a per-application routing table by bundle id or process name without hand-editing JSON and counting braces.
- Re-pointing a profile at a different proxy host and a different set of credentials before handing it to a teammate.
- Moving a profile between the macOS sample field style and the cross-platform / CLI style while the rules stay intact.
- Auditing which processes a profile proxies, which it sends direct and which it blocks, on a machine without the application installed.
When to use something else
- Cleaning up a list of proxy addresses collected from several sources. Proxy Formatter normalizes the addresses first; type the result into the proxy forms here.
- Checking whether a proxy responds or accepts your credentials. Batch Proxy Checker is the tool for that, on a list you are authorized to test; this editor makes no network connections at all.
- Applying rules to live traffic. The download is a configuration file — the installed ProxyBridge application is what routes anything.
Privacy and data handling
The file is parsed with the browser's JSON parser, edited in memory, re-serialized in this tab and handed to you as a local download. Nothing reaches this site, and no copy is kept on a server. The two local traces are worth knowing about: Save to browser history keeps up to twelve complete profile snapshots in this browser's localStorage, and those snapshots include any proxy password you entered. The downloaded file itself stores the username and password as ordinary JSON strings, so it is a credential file — do not attach it to a ticket, and delete it from a machine that is not yours.
Related developer tools
Frequently asked questions
Can I edit a .pbprofile without installing the application?
Yes. The file is ordinary JSON, and this page parses, edits and re-serializes it in the browser. What it cannot do is apply the profile or verify that the proxies inside it work.
Which field styles does it read?
Both. A document using the camelCase proxyConfigs and proxyRules keys is read as the macOS sample style; anything else is read as the cross-platform / CLI style with its PascalCase keys. Either style can be exported afterwards, but a few profile-level settings and the rule names only exist in one of them.
Will my proxy password be uploaded?
No. Everything happens in this tab and the file is downloaded locally. The password is stored in clear text inside the downloaded JSON, and Save to browser history keeps a full copy in this browser's localStorage on your own device, so treat both as secrets.
Why does the application reject or ignore my file?
The usual causes are the extension being rewritten during download, and a style mismatch — a file written with PascalCase keys where the application expects the camelCase shape, or the reverse. Export a profile from the application itself and compare the top-level key names with yours.
Can I convert a Proxifier profile into a .pbprofile?
Not automatically. Proxy definitions and the Direct, Proxy and Block rules map onto DIRECT, PROXY and BLOCK by hand, but Proxifier chains have no equivalent here, and ProxyBridge's per-rule protocol selection has no counterpart there. Keep the Proxifier Profile Editor open beside this one and copy the fields across.
What does the protocol setting do?
It limits a rule to TCP, to UDP, or to both. Splitting a rule in two is useful when a process should be proxied for TCP but left direct for UDP; on macOS, UDP matching leans on the process and bundle-id fields rather than the target host.
Is this site affiliated with ProxyBridge?
No. This is an independent editor for the .pbprofile file format. ProxyBridge belongs to its own developer, and that name and any related trademarks belong to their respective owner.