Transform Rules: URL Rewriting at the Cloudflare Edge

Most URLs are built for machines, not people. Auto-generated strings and opaque database identifiers may be efficient for an origin server, but they offer little to a human trying to make sense of a link before clicking it. URL rewriting has long been the standard way for websites to present clean, memorable addresses while keeping the underlying request format simple for back-end systems to parse.

Cloudflare has now made that interpretation layer available as Transform Rules on all plans. The rules let administrators rewrite the URI path and query of incoming HTTP requests as they hit the Cloudflare edge, before anything else on the platform processes the traffic.

Why rewrite at the edge

Consider an ecommerce listing such as https://www.travelbooks247.com/dp/0596523203/. It works, but it is not particularly inviting. A friendlier URL such as https://www.travelbooks247.com/Geek-Atlas-Places-Science-Technology/dp/0596523203/ conveys meaning, and the web server strip out the descriptive segment before forwarding the request upstream.

That pattern used to be trivial for anyone with direct access to their own web server, using modules like mod_rewrite or ngx_http_rewrite_module. But as applications migrate to managed platforms and cloud services, the origin server is often no longer something the administrator controls. Rewriting rules historically lived on that server, and losing access to it meant losing the ability to shape requests. Transform Rules put that control back in the administrator's hands, applying rewrites at the edge to traffic headed for servers you do not manage.

Static and dynamic rewrites

The initial release of Transform Rules ships with one action: rewrite. You can match on HTTP requests and replace the URI path or query with either a static or a dynamic value.

A static rewrite is a straight substitution. For instance, all traffic at /index.php can be rewritten to /landing.php:

Dynamic URL Rewriting at the edge with Cloudflare Embedded Image - kXuLpm
Dynamic rewrites use Cloudflare's expression language to transform matching traffic based on patterns. Suppose you want to map www.example.com/assets/* to www.example.com/internal/files/assets/*. The regex_replace() function can modify part of the path using an RE-2 compatible regular expression:

Dynamic URL Rewriting at the edge with Cloudflare Embedded Image - odrPKF
The expression engine also provides concat() for string concatenation. To move all requests with the path /news/2012/* under a new archive prefix, you could construct:

Dynamic URL Rewriting at the edge with Cloudflare Embedded Image - 0Twc4c
Rewrites can target the URI path and URI query together or independently. Setting up a static rewrite on the query and leaving the replacement blank will remove the query string from matching requests:

Dynamic URL Rewriting at the edge with Cloudflare Embedded Image - KmLVfs
That sort of rule has practical uses in SEO hygiene and in preventing cache poisoning, where varied query strings cause storage of duplicate cached objects.

Timing within the Cloudflare flow

One design decision asked during testing was where the rewrite should happen in relation to other Cloudflare products. The original prototype bolted the rewrite action onto Firewall Rules, sharing the same underlying engine. That approach, however, produced a subtle ordering problem: if a rewrite transformed /soccer/* into /football/*, should a Page Rule or Worker that filters on football see the rewritten or original URL?

For predictability, Cloudflare chose to execute URL rewrite rules immediately as the request enters the edge. Firewall Rules, Page Rules, Workers, and everything else downstream therefore see a consistent, rewritten URL. That simplifies the mental model significantly: the URL arriving at any later product in the stack is exactly the result of the rewrite, no more guesswork.

Redirect vs. rewrite

It is worth being explicit about what a rewrite is not. A URL redirect, sometimes called forwarding, returns a response that instructs the client to request a different URL. The address in the browser bar changes. A URL rewrite, by contrast, modifies the request on the server side before the origin processes it; the browser's address bar is left untouched. The two operations solve different problems, and Transform Rules are rewrites — they change what the origin sees, not what the user is told to visit.

URL normalization as a security layer

Alongside Transform Rules, Cloudflare has enabled URL normalization on all zones. Previously, Cloudflare products treated the URI of an incoming request literally when comparing it against filters. A request to https://example.com/%6ogin would only be blocked if an administrator created a rule matching the encoded variant /%ogin. The obvious risk is attackers skipping around security filters with different URL-encoded forms of the same path.

Normalization addresses that by converting inbound traffic to a standard format before it reaches Firewall Rules, Page Rules, Workers, and other products. For most zones this was enabled by default ahead of the announcement. The result is simpler rule authoring — matching /login blocks the encoded attempts too — and a narrower attack surface.

A new home in the dashboard

The edge navigation bar now lists a single Rules entry, with Page Rules grouped alongside Transform Rules. The move keeps the existing Page Rules API endpoints intact while making room for additional rule types as they arrive. Subsequent Transform Rule actions, such as HTTP request header modification, are planned for the near future.