diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
index 9efb6ed7d18c4ec..5023d100a0de5ce 100644
--- a/.github/CODEOWNERS
+++ b/.github/CODEOWNERS
@@ -123,6 +123,8 @@
 /src/content/docs/workers/runtime-apis/bindings/ @irvinebroque @mikenomitch @GregBrimble @cloudflare/pcx-technical-writing
 /src/content/docs/workers/platform/ @irvinebroque @tanushree-sharma @GregBrimble @cloudflare/deploy-config @cloudflare/pcx-technical-writing
 /src/content/docs/workers/configuration/compatibility-dates/ @irvinebroque @mikenomitch @GregBrimble @cloudflare/deploy-config @cloudflare/pcx-technical-writing
+/src/content/docs/workers/configuration/compatibility-flags/ @irvinebroque @mikenomitch @GregBrimble @cloudflare/deploy-config @cloudflare/pcx-technical-writing
+
 /src/content/docs/workers/reference/migrate-to-module-workers/ @irvinebroque @GregBrimble @cloudflare/deploy-config @cloudflare/pcx-technical-writing
 /src/content/docs/workers/reference/security-model/ @irvinebroque @GregBrimble @cloudflare/pcx-technical-writing
 /src/content/compatibility-dates/ @irvinebroque @kflansburg @mikenomitch @GregBrimble @cloudflare/pcx-technical-writing
diff --git a/src/content/changelogs/queues.yaml b/src/content/changelogs/queues.yaml
index 4571310f8b8b734..4af0d1031004bbf 100644
--- a/src/content/changelogs/queues.yaml
+++ b/src/content/changelogs/queues.yaml
@@ -31,7 +31,7 @@ entries:
     description: |-
       The default [content type](/queues/configuration/javascript-apis/#queuescontenttype) for messages published to a queue is now `json`, which improves compatibility with the upcoming pull-based queues.
 
-      Any Workers created on or after the [compatibility date](/workers/configuration/compatibility-dates/#queues-send-messages-in-json-format) of `2024-03-18`, or that explicitly set the `queues_json_messages` compatibility flag, will use the new default behaviour. Existing Workers with a compatibility date prior will continue to use `v8` as the default content type for published messages.
+      Any Workers created on or after the [compatibility date](/workers/configuration/compatibility-flags/#queues-send-messages-in-json-format) of `2024-03-18`, or that explicitly set the `queues_json_messages` compatibility flag, will use the new default behaviour. Existing Workers with a compatibility date prior will continue to use `v8` as the default content type for published messages.
   - publish_date: "2024-02-24"
     title: Explicit retries no longer impact consumer concurrency/scaling.
     description: |-
diff --git a/src/content/changelogs/vectorize.yaml b/src/content/changelogs/vectorize.yaml
index 57fb9b9ffcc8c79..4b9116bb16ad219 100644
--- a/src/content/changelogs/vectorize.yaml
+++ b/src/content/changelogs/vectorize.yaml
@@ -56,7 +56,7 @@ entries:
     description: |-
       Vectorize `/query` HTTP endpoint has the following changes:
       - `returnVectors` request body property is deprecated in favor of `returnValues` and `returnMetadata` properties.
-      - Response format has changed to the below format to match [Workers API change]:(/workers/configuration/compatibility-dates/#vectorize-query-with-metadata-optionally-returned)
+      - Response format has changed to the below format to match [Workers API change]:(/workers/configuration/compatibility-flags/#vectorize-query-with-metadata-optionally-returned)
 
       ```json
       {
diff --git a/src/content/changelogs/workers.yaml b/src/content/changelogs/workers.yaml
index e7409d2c529bf20..23494c535f7dd8d 100644
--- a/src/content/changelogs/workers.yaml
+++ b/src/content/changelogs/workers.yaml
@@ -25,7 +25,7 @@ entries:
       - Updated v8 to version 12.9.
   - publish_date: "2024-08-19"
     description: |-
-      -  Workers now support the [`allow_custom_ports` compatibility flag](/workers/configuration/compatibility-dates/#allow-specifying-a-custom-port-when-making-a-subrequest-with-the-fetch-api) which enables using the `fetch()` calls to custom ports.
+      -  Workers now support the [`allow_custom_ports` compatibility flag](/workers/configuration/compatibility-flags/#allow-specifying-a-custom-port-when-making-a-subrequest-with-the-fetch-api) which enables using the `fetch()` calls to custom ports.
   - publish_date: "2024-08-15"
     description: |-
       - Updated v8 to version 12.8.
@@ -80,12 +80,12 @@ entries:
       - Updated v8 to version 12.6.
   - publish_date: "2024-05-15"
     description: |-
-      - The new [`fetch_standard_url` compatibility flag](/workers/configuration/compatibility-dates/#use-standard-url-parsing-in-fetch) will become active by default on June 3rd, 2024 and ensures that URLs passed into the `fetch(...)` API, the `new Request(...)` constructor, and redirected requests will be parsed using the standard WHATWG URL parser.
+      - The new [`fetch_standard_url` compatibility flag](/workers/configuration/compatibility-flags/#use-standard-url-parsing-in-fetch) will become active by default on June 3rd, 2024 and ensures that URLs passed into the `fetch(...)` API, the `new Request(...)` constructor, and redirected requests will be parsed using the standard WHATWG URL parser.
       - DigestStream is now more efficient and exposes a new `bytesWritten` property that indicates that number of bytes written to the digest.
   - publish_date: "2024-05-13"
     description: |-
       - Updated v8 to version 12.5.
-      - A bug in the fetch API implementation would cause the content type of a Blob to be incorrectly set. The fix is being released behind a new [`blob_standard_mime_type` compatibility flag](/workers/configuration/compatibility-dates/#properly-extract-blob-mime-type-from-content-type-headers).
+      - A bug in the fetch API implementation would cause the content type of a Blob to be incorrectly set. The fix is being released behind a new [`blob_standard_mime_type` compatibility flag](/workers/configuration/compatibility-flags/#properly-extract-blob-mime-type-from-content-type-headers).
   - publish_date: "2024-05-03"
     description: |-
       - Fixed RPC to/from Durable Objects not honoring the output gate.
@@ -108,13 +108,13 @@ entries:
       - The Web standard `ReadableStream.from()` API is now implemented. The API enables creating a `ReadableStream` from a either a sync or async iterable.
   - publish_date: "2024-04-03"
     description: |-
-      - When the [`brotli_content_encoding`](/workers/configuration/compatibility-dates/#brotli-content-encoding-support) compatibility flag is enabled, the Workers runtime now supports compressing and decompressing request bodies encoded using the [Brotli](https://developer.mozilla.org/en-US/docs/Glossary/Brotli_compression) compression algorithm. Refer to [this docs section](/workers/runtime-apis/fetch/#how-the-accept-encoding-header-is-handled) for more detail.
+      - When the [`brotli_content_encoding`](/workers/configuration/compatibility-flags/#brotli-content-encoding-support) compatibility flag is enabled, the Workers runtime now supports compressing and decompressing request bodies encoded using the [Brotli](https://developer.mozilla.org/en-US/docs/Glossary/Brotli_compression) compression algorithm. Refer to [this docs section](/workers/runtime-apis/fetch/#how-the-accept-encoding-header-is-handled) for more detail.
   - publish_date: "2024-04-02"
     description: |-
       - You can now [write Workers in Python](/workers/languages/python)
   - publish_date: "2024-04-01"
     description: |-
-      - The new [`unwrap_custom_thenables` compatibility flag](/workers/configuration/compatibility-dates/#handling-custom-thenables) enables workers to accept custom thenables in internal APIs that expect a promise (for instance, the `ctx.waitUntil(...)` method).
+      - The new [`unwrap_custom_thenables` compatibility flag](/workers/configuration/compatibility-flags/#handling-custom-thenables) enables workers to accept custom thenables in internal APIs that expect a promise (for instance, the `ctx.waitUntil(...)` method).
       - TransformStreams created with the TransformStream constructor now have a cancel algorithm that is called when the stream is canceled or aborted. This change is part of the implementation of the WHATWG Streams standard.
       - The [`nodejs_compat` compatibility flag](/workers/runtime-apis/nodejs/) now includes an implementation of the [`MockTracker` API from `node:test`](https://nodejs.org/api/test.html#class-mocktracker). This is not an implementation of the full `node:test` module, and mock timers are currently not included.
       - Exceptions reported to [Tail Workers](/workers/observability/logs/tail-workers/) now include a "stack" property containing the exception's stack trace, if available.
@@ -143,7 +143,7 @@ entries:
       - Workers and Pages Functions on the Standard usage model can set custom [CPU limits](/workers/wrangler/configuration/#limits) for their Workers
   - publish_date: "2023-10-20"
     description: |-
-      - Added the [`crypto_preserve_public_exponent`](/workers/configuration/compatibility-dates/#webcrypto-preserve-publicexponent-field)
+      - Added the [`crypto_preserve_public_exponent`](/workers/configuration/compatibility-flags/#webcrypto-preserve-publicexponent-field)
         compatibility flag to correct a wrong type being used in the algorithm field of RSA keys in
         the WebCrypto API.
   - publish_date: "2023-10-18"
@@ -156,7 +156,7 @@ entries:
   - publish_date: "2023-10-09"
     description: |-
       - The Web Platform standard [`CustomEvent` class](https://dom.spec.whatwg.org/#interface-customevent) is now available in Workers.
-      - Fixed a bug in the WebCrypto API where the `publicExponent` field of the algorithm of RSA keys would have the wrong type. Use the [`crypto_preserve_public_exponent` compatibility flag](/workers/configuration/compatibility-dates/#webcrypto-preserve-publicexponent-field) to enable the new behavior.
+      - Fixed a bug in the WebCrypto API where the `publicExponent` field of the algorithm of RSA keys would have the wrong type. Use the [`crypto_preserve_public_exponent` compatibility flag](/workers/configuration/compatibility-flags/#webcrypto-preserve-publicexponent-field) to enable the new behavior.
   - publish_date: "2023-09-14"
     description: |-
       - An implementation of the [`node:crypto`](/workers/runtime-apis/nodejs/crypto/)
@@ -173,7 +173,7 @@ entries:
       - An implementation of the [`diagnostics_channel`](/workers/runtime-apis/nodejs/diagnostics-channel) API from Node.js is now available when using the `nodejs_compat` compatibility flag.
   - publish_date: "2023-06-22"
     description: |-
-      - Added the [`strict_crypto_checks`](/workers/configuration/compatibility-dates/#strict-crypto-error-checking) compatibility flag to enable additional [Web Crypto API](/workers/runtime-apis/web-crypto/) error and security checking.
+      - Added the [`strict_crypto_checks`](/workers/configuration/compatibility-flags/#strict-crypto-error-checking) compatibility flag to enable additional [Web Crypto API](/workers/runtime-apis/web-crypto/) error and security checking.
       - Fixes regression in the [TCP Sockets API](/workers/runtime-apis/tcp-sockets/) where `connect("google.com:443")` would fail with a `TypeError`.
   - publish_date: "2023-06-19"
     description: |-
@@ -183,8 +183,8 @@ entries:
     description: |-
       - `AbortSignal.any()` is now available.
       - Updated V8 to 11.4.
-      - Following an update to the [WHATWG URL spec](https://url.spec.whatwg.org/#interface-urlsearchparams), the `delete()` and `has()` methods of the `URLSearchParams` class now accept an optional second argument to specify the search parameter’s value. This is potentially a breaking change, so it is gated behind the new `urlsearchparams_delete_has_value_arg` and [`url_standard`](/workers/configuration/compatibility-dates/#new-url-parser-implementation) compatibility flags.
-      - Added the [`strict_compression_checks`](/workers/configuration/compatibility-dates/#strict-compression-error-checking) compatibility flag for additional [`DecompressionStream`](/workers/runtime-apis/web-standards/#compression-streams) error checking.
+      - Following an update to the [WHATWG URL spec](https://url.spec.whatwg.org/#interface-urlsearchparams), the `delete()` and `has()` methods of the `URLSearchParams` class now accept an optional second argument to specify the search parameter’s value. This is potentially a breaking change, so it is gated behind the new `urlsearchparams_delete_has_value_arg` and [`url_standard`](/workers/configuration/compatibility-flags/#new-url-parser-implementation) compatibility flags.
+      - Added the [`strict_compression_checks`](/workers/configuration/compatibility-flags/#strict-compression-error-checking) compatibility flag for additional [`DecompressionStream`](/workers/runtime-apis/web-standards/#compression-streams) error checking.
   - publish_date: "2023-05-26"
     description: |-
       - A new [Hibernatable WebSockets API](/durable-objects/api/websockets/)
diff --git a/src/content/compatibility-dates/new-url-parser-implementation.md b/src/content/compatibility-dates/new-url-parser-implementation.md
index 217b490ae9b7acb..55b21a5be67018c 100644
--- a/src/content/compatibility-dates/new-url-parser-implementation.md
+++ b/src/content/compatibility-dates/new-url-parser-implementation.md
@@ -27,4 +27,4 @@ The original implementation of the [`URL`](https://developer.mozilla.org/en-US/d
 
 Set the compatibility date of your Worker to a date after `2022-10-31` or enable the `url_standard` compatibility flag to opt-in the fully spec compliant `URL` API implementation.
 
-Refer to the [`response_redirect_url_standard` compatibility flag](/workers/configuration/compatibility-dates/#use-a-spec-compliant-url-implementation-in-redirects) , which affects the URL implementation used in `Response.redirect()`.
+Refer to the [`response_redirect_url_standard` compatibility flag](/workers/configuration/compatibility-flags/#use-a-spec-compliant-url-implementation-in-redirects) , which affects the URL implementation used in `Response.redirect()`.
diff --git a/src/content/docs/browser-rendering/get-started/browser-rendering-with-DO.mdx b/src/content/docs/browser-rendering/get-started/browser-rendering-with-DO.mdx
index e7c347452e8a7c6..0feb0789b7100cc 100644
--- a/src/content/docs/browser-rendering/get-started/browser-rendering-with-DO.mdx
+++ b/src/content/docs/browser-rendering/get-started/browser-rendering-with-DO.mdx
@@ -71,7 +71,7 @@ After running the `list` command, you will see all bucket names, including the o
 
 ## 5. Configure `wrangler.toml`
 
-Configure your `browser-worker` project's [`wrangler.toml`](/workers/wrangler/configuration/) file by adding a browser [binding](/workers/runtime-apis/bindings/) and a [Node.js compatibility flag](/workers/configuration/compatibility-dates/#nodejs-compatibility-flag). Browser bindings allow for communication between a Worker and a headless browser which allows you to do actions such as taking a screenshot, generating a PDF and more.
+Configure your `browser-worker` project's [`wrangler.toml`](/workers/wrangler/configuration/) file by adding a browser [binding](/workers/runtime-apis/bindings/) and a [Node.js compatibility flag](/workers/configuration/compatibility-flags/#nodejs-compatibility-flag). Browser bindings allow for communication between a Worker and a headless browser which allows you to do actions such as taking a screenshot, generating a PDF and more.
 
 Update your `wrangler.toml` configuration file with the Browser Rendering API binding, the R2 bucket you created and a Durable Object:
 
diff --git a/src/content/docs/browser-rendering/get-started/screenshots.mdx b/src/content/docs/browser-rendering/get-started/screenshots.mdx
index d8cabbbeb5fa364..3144643e97565f9 100644
--- a/src/content/docs/browser-rendering/get-started/screenshots.mdx
+++ b/src/content/docs/browser-rendering/get-started/screenshots.mdx
@@ -58,7 +58,7 @@ Take note of the IDs for the next step.
 
 ## 4. Configure `wrangler.toml`
 
-Configure your `browser-worker` project's [`wrangler.toml`](/workers/wrangler/configuration/) file by adding a browser [binding](/workers/runtime-apis/bindings/) and a [Node.js compatibility flag](/workers/configuration/compatibility-dates/#nodejs-compatibility-flag). Bindings allow your Workers to interact with resources on the Cloudflare developer platform. Your browser `binding` name is set by you, this guide uses the name `MYBROWSER`. Browser bindings allow for communication between a Worker and a headless browser which allows you to do actions such as taking a screenshot, generating a PDF and more.
+Configure your `browser-worker` project's [`wrangler.toml`](/workers/wrangler/configuration/) file by adding a browser [binding](/workers/runtime-apis/bindings/) and a [Node.js compatibility flag](/workers/configuration/compatibility-flags/#nodejs-compatibility-flag). Bindings allow your Workers to interact with resources on the Cloudflare developer platform. Your browser `binding` name is set by you, this guide uses the name `MYBROWSER`. Browser bindings allow for communication between a Worker and a headless browser which allows you to do actions such as taking a screenshot, generating a PDF and more.
 
 Update your `wrangler.toml` configuration file with the Browser Rendering API binding and the KV namespaces you created:
 
diff --git a/src/content/docs/durable-objects/api/webgpu.mdx b/src/content/docs/durable-objects/api/webgpu.mdx
index 008cf2f2a389737..0901d40d5ae8044 100644
--- a/src/content/docs/durable-objects/api/webgpu.mdx
+++ b/src/content/docs/durable-objects/api/webgpu.mdx
@@ -15,7 +15,7 @@ The [WebGPU API](https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API) al
 
 The WebGPU API is only accessible from within [Durable Objects](/durable-objects/). You cannot use the WebGPU API from within Workers.
 
-To use the WebGPU API in local development, enable the `experimental` and `webgpu` [compatibility flags](/workers/configuration/compatibility-dates/#compatibility-flags) in the [`wrangler.toml` configuration file](/workers/wrangler/configuration/) of your Durable Object.
+To use the WebGPU API in local development, enable the `experimental` and `webgpu` [compatibility flags](/workers/configuration/compatibility-flags/) in the [`wrangler.toml` configuration file](/workers/wrangler/configuration/) of your Durable Object.
 
 ```
 compatibility_flags = ["experimental", "webgpu"]
diff --git a/src/content/docs/durable-objects/best-practices/create-durable-object-stubs-and-send-requests.mdx b/src/content/docs/durable-objects/best-practices/create-durable-object-stubs-and-send-requests.mdx
index bdf8bb6e9e99305..b88268d27087972 100644
--- a/src/content/docs/durable-objects/best-practices/create-durable-object-stubs-and-send-requests.mdx
+++ b/src/content/docs/durable-objects/best-practices/create-durable-object-stubs-and-send-requests.mdx
@@ -9,7 +9,7 @@ import { Render, Tabs, TabItem, GlossaryTooltip } from "~/components";
 
 ## Invoking methods on a Durable Object
 
-All new projects and existing projects with a compatibility date greater than or equal to [`2024-04-03`](/workers/configuration/compatibility-dates/#durable-object-stubs-and-service-bindings-support-rpc) should prefer to invoke [Remote Procedure Call (RPC)](/workers/runtime-apis/rpc/) methods defined on a <GlossaryTooltip term="Durable Object class">Durable Object class</GlossaryTooltip>. Legacy projects can continue to invoke the `fetch` handler on the Durable Object class indefinitely.
+All new projects and existing projects with a compatibility date greater than or equal to [`2024-04-03`](/workers/configuration/compatibility-flags/#durable-object-stubs-and-service-bindings-support-rpc) should prefer to invoke [Remote Procedure Call (RPC)](/workers/runtime-apis/rpc/) methods defined on a <GlossaryTooltip term="Durable Object class">Durable Object class</GlossaryTooltip>. Legacy projects can continue to invoke the `fetch` handler on the Durable Object class indefinitely.
 
 ### Invoke RPC methods
 
@@ -29,7 +29,7 @@ Refer to [Build a Counter](/durable-objects/examples/build-a-counter/) for a com
 
 ### Invoking the `fetch` handler
 
-If your project is stuck on a compatibility date before [`2024-04-03`](/workers/configuration/compatibility-dates/#durable-object-stubs-and-service-bindings-support-rpc), or has the need to send a [`Request`](/workers/runtime-apis/request/) object and return a `Response` object, then you should send requests to a Durable Object via the fetch handler.
+If your project is stuck on a compatibility date before [`2024-04-03`](/workers/configuration/compatibility-flags/#durable-object-stubs-and-service-bindings-support-rpc), or has the need to send a [`Request`](/workers/runtime-apis/request/) object and return a `Response` object, then you should send requests to a Durable Object via the fetch handler.
 
 <Tabs> <TabItem label="JavaScript" icon="seti:javascript">
 
diff --git a/src/content/docs/queues/configuration/javascript-apis.mdx b/src/content/docs/queues/configuration/javascript-apis.mdx
index 4a0eb76a31f2076..0da09622e57a34e 100644
--- a/src/content/docs/queues/configuration/javascript-apis.mdx
+++ b/src/content/docs/queues/configuration/javascript-apis.mdx
@@ -139,7 +139,7 @@ type QueuesContentType = "text" | "bytes" | "json" | "v8";
 :::note
 
 
-The default content type for Queues changed to `json` (from `v8`) to improve compatibility with pull-based consumers for any Workers with a [compatibility date](/workers/configuration/compatibility-dates/#queues-send-messages-in-json-format) after `2024-03-18`.
+The default content type for Queues changed to `json` (from `v8`) to improve compatibility with pull-based consumers for any Workers with a [compatibility date](/workers/configuration/compatibility-flags/#queues-send-messages-in-json-format) after `2024-03-18`.
 
 
 :::
diff --git a/src/content/docs/workers/configuration/compatibility-dates.mdx b/src/content/docs/workers/configuration/compatibility-dates.mdx
index a9f4ea1921ab326..8b8acd9d40eb069 100644
--- a/src/content/docs/workers/configuration/compatibility-dates.mdx
+++ b/src/content/docs/workers/configuration/compatibility-dates.mdx
@@ -6,11 +6,9 @@ head: []
 description: Opt into a specific version of the Workers runtime for your Workers project.
 ---
 
-import { CompatibilityDates } from "~/components";
-
 Cloudflare regularly updates the Workers runtime. These updates apply to all Workers globally and should never cause a Worker that is already deployed to stop functioning. Sometimes, though, some changes may be backwards-incompatible. In particular, there might be bugs in the runtime API that existing Workers may inadvertently depend upon. Cloudflare implements bug fixes that new Workers can opt into while existing Workers will continue to see the buggy behavior to prevent breaking deployed Workers.
 
-The compatibility date (and flags) are how you, as a developer, opt into these runtime changes. Compatibility flags will often have a date in which they are enabled by default, and so, by specifying a `compatibility_date` for your Worker, you can quickly enable all of these various compatibility flags up to, and including, that date.
+The compatibility date and flags are how you, as a developer, opt into these runtime changes. [Compatibility flags](/workers/configuration/compatibility-flags) will often have a date in which they are enabled by default, and so, by specifying a `compatibility_date` for your Worker, you can quickly enable all of these various compatibility flags up to, and including, that date.
 
 ## Setting compatibility date
 
@@ -43,68 +41,3 @@ The compatibility date cannot be updated on the Cloudflare Dashboard at this tim
 The compatibility date can be set when uploading a Worker using the [Workers Script API](/api/operations/worker-script-upload-worker-module) or [Workers Versions API](/api/operations/worker-versions-upload-version#request-body) in the request body's `metadata` field.
 
 If a compatibility date is not specified on upload via the API, it defaults to the oldest compatibility date, before any flags took effect (2021-11-02). When creating new Workers, it is highly recommended to set the compatibility date to the current date when uploading via the API.
-
-## Setting compatibility flags
-
-In addition to setting a `compatibility_date`, you may also provide a list of `compatibility_flags`, which enable or disable specific changes.
-
-Most developers will not need to use `compatibility_flags`. `compatibility_flags` can be useful if you want to help the Workers team test upcoming changes that are not yet enabled by default, or if you need to hold back a change that your code depends on but still want to apply other compatibility changes.
-
-#### Via Wrangler
-
-Compatibility flags can be set in a Worker's [`wrangler.toml`](/workers/wrangler/configuration/) file.
-
-This example enables the specific flag `formdata_parser_supports_files`, which is described [below](/workers/configuration/compatibility-dates/#formdata-parsing-supports-file). As of the specified date, `2021-09-14`, this particular flag was not yet enabled by default, but, by specifying it in `compatibility_flags`, we can enable it anyway. `compatibility_flags` can also be used to disable changes that became the default in the past.
-
-```toml
-# Opt into backwards-incompatible changes through September 14, 2021.
-compatibility_date = "2021-09-14"
-# Also opt into an upcoming fix to the FormData API.
-compatibility_flags = [ "formdata_parser_supports_files" ]
-```
-
-#### Via the Cloudflare Dashboard
-
-Compatibility flags cannot be set or updated on the Cloudflare Dashboard at this time.
-
-#### Via the Cloudflare API
-
-Compatibility flags can be set when uploading a Worker using the [Workers Script API](/api/operations/worker-script-upload-worker-module) or [Workers Versions API](/api/operations/worker-versions-upload-version#request-body) in the request body's `metadata` field.
-
-## Compatibility flags
-
-### Node.js compatibility flag
-
-:::note
-You can opt into improved Node.js compatibility by using `nodejs_compat_v2` instead of `nodejs_compat`. This provides the functionality of `nodejs_compat`, but
-additionally you can import Node.js modules without the `node:` prefix and use polyfilled Node.js modules and globals that are not available with `nodejs_compat`.
-
-On September 23, 2024, `nodejs_compat` will use the improved Node.js compatibility currently enabled with `nodejs_compat_v2`. This will require updating your
-compatability_date to 2024-09-23 or later.
-:::
-
-A [growing subset](/workers/runtime-apis/nodejs/) of Node.js APIs are available directly as [Runtime APIs](/workers/runtime-apis/nodejs), with no need to add polyfills to your own code. To enable these APIs in your Worker, add the `nodejs_compat` compatibility flag to your `wrangler.toml`:
-
-```toml title="wrangler.toml"
-compatibility_flags = [ "nodejs_compat" ]
-```
-
-As additional Node.js APIs are added, they will be made available under the `nodejs_compat` compatibility flag. Unlike most other compatibility flags, we do not expect the `nodejs_compat` to become active by default at a future date.
-
-The Node.js `AsyncLocalStorage` API is a particularly useful feature for Workers. To enable only the `AsyncLocalStorage` API, use the `nodejs_als` compatibility flag.
-
-```toml title="wrangler.toml"
-compatibility_flags = [ "nodejs_als" ]
-```
-
-## Change history
-
-Newest changes are listed first.
-
-<CompatibilityDates />
-
-## Experimental changes
-
-These changes can be enabled via `compatibility_flags`, but are not yet scheduled to become default on any particular date.
-
-<CompatibilityDates experimental />
diff --git a/src/content/docs/workers/configuration/compatibility-flags.mdx b/src/content/docs/workers/configuration/compatibility-flags.mdx
new file mode 100644
index 000000000000000..e689ef2c3eee4bc
--- /dev/null
+++ b/src/content/docs/workers/configuration/compatibility-flags.mdx
@@ -0,0 +1,74 @@
+---
+pcx_content_type: concept
+title: Compatibility flags
+rss: https://github.com/cloudflare/cloudflare-docs/commits/production/src/content/compatibility-flags.atom
+head: []
+description: Opt into a specific features of the Workers runtime for your Workers project.
+---
+
+import { CompatibilityDates } from "~/components";
+
+Compatibility flags enable specific features. They can be useful if you want to help the Workers team test upcoming changes that are not yet enabled by default, or if you need to hold back a change that your code depends on but still want to apply other compatibility changes.
+
+Compatibility flags will often have a date in which they are enabled by default, and so, by specifying a [`compatibility_date`](/workers/configuration/compatibility-dates) for your Worker, you can quickly enable all of these various compatibility flags up to, and including, that date.
+
+## Setting compatibility flags
+
+You may provide a list of `compatibility_flags`, which enable or disable specific changes.
+
+#### Via Wrangler
+
+Compatibility flags can be set in a Worker's [`wrangler.toml`](/workers/wrangler/configuration/) file.
+
+This example enables the specific flag `formdata_parser_supports_files`, which is described [below](/workers/configuration/compatibility-flags/#formdata-parsing-supports-file). As of the specified date, `2021-09-14`, this particular flag was not yet enabled by default, but, by specifying it in `compatibility_flags`, we can enable it anyway. `compatibility_flags` can also be used to disable changes that became the default in the past.
+
+```toml
+# Opt into backwards-incompatible changes through September 14, 2021.
+compatibility_date = "2021-09-14"
+# Also opt into an upcoming fix to the FormData API.
+compatibility_flags = [ "formdata_parser_supports_files" ]
+```
+
+#### Via the Cloudflare Dashboard
+
+Compatibility flags cannot be set or updated on the Cloudflare Dashboard at this time.
+
+#### Via the Cloudflare API
+
+Compatibility flags can be set when uploading a Worker using the [Workers Script API](/api/operations/worker-script-upload-worker-module) or [Workers Versions API](/api/operations/worker-versions-upload-version#request-body) in the request body's `metadata` field.
+
+## Node.js compatibility flag
+
+:::note
+You can opt into improved Node.js compatibility by using `nodejs_compat_v2` instead of `nodejs_compat`. This provides the functionality of `nodejs_compat`, but
+additionally you can import Node.js modules without the `node:` prefix and use polyfilled Node.js modules and globals that are not available with `nodejs_compat`.
+
+On September 23, 2024, `nodejs_compat` will use the improved Node.js compatibility currently enabled with `nodejs_compat_v2`. This will require updating your
+compatibility_date to 2024-09-23 or later.
+:::
+
+A [growing subset](/workers/runtime-apis/nodejs/) of Node.js APIs are available directly as [Runtime APIs](/workers/runtime-apis/nodejs), with no need to add polyfills to your own code. To enable these APIs in your Worker, add the `nodejs_compat` compatibility flag to your `wrangler.toml`:
+
+```toml title="wrangler.toml"
+compatibility_flags = [ "nodejs_compat" ]
+```
+
+As additional Node.js APIs are added, they will be made available under the `nodejs_compat` compatibility flag. Unlike most other compatibility flags, we do not expect the `nodejs_compat` to become active by default at a future date.
+
+The Node.js `AsyncLocalStorage` API is a particularly useful feature for Workers. To enable only the `AsyncLocalStorage` API, use the `nodejs_als` compatibility flag.
+
+```toml title="wrangler.toml"
+compatibility_flags = [ "nodejs_als" ]
+```
+
+## Change history
+
+Newest changes are listed first.
+
+<CompatibilityDates />
+
+## Experimental changes
+
+These changes can be enabled via `compatibility_flags`, but are not yet scheduled to become default on any particular date.
+
+<CompatibilityDates experimental />
diff --git a/src/content/docs/workers/configuration/multipart-upload-metadata.mdx b/src/content/docs/workers/configuration/multipart-upload-metadata.mdx
index 25fac9277146fe4..c52195b1d2d7606 100644
--- a/src/content/docs/workers/configuration/multipart-upload-metadata.mdx
+++ b/src/content/docs/workers/configuration/multipart-upload-metadata.mdx
@@ -30,7 +30,7 @@ The following attributes are configurable at the top-level.
 
 :::note
 
-At a minimum, the `main_module` key is required to upload a Worker. 
+At a minimum, the `main_module` key is required to upload a Worker.
 :::
 
 
@@ -54,7 +54,7 @@ At a minimum, the `main_module` key is required to upload a Worker.
 
 * `compatibility_flags` array\[string] optional
 
-  * [Compatibility Flags](/workers/configuration/compatibility-dates/#setting-compatibility-flags) that enable or disable certain features in the Workers runtime. Used to enable upcoming features or opt in or out of specific changes not included in a `compatibility_date`.
+  * [Compatibility Flags](/workers/configuration/compatibility-flags/#setting-compatibility-flags) that enable or disable certain features in the Workers runtime. Used to enable upcoming features or opt in or out of specific changes not included in a `compatibility_date`.
 
 * `usage_model` <Type text="string" /> <MetaInfo text="optional" />
 
@@ -68,7 +68,7 @@ For [immediately deployed uploads](/workers/configuration/versions-and-deploymen
 
 :::note
 
-These attributes are **not available** for version uploads. 
+These attributes are **not available** for version uploads.
 :::
 
 
@@ -97,7 +97,7 @@ For [version uploads](/workers/configuration/versions-and-deployments/#upload-a-
 
 :::note
 
-These attributes are **not available** for immediately deployed uploads. 
+These attributes are **not available** for immediately deployed uploads.
 :::
 
 
diff --git a/src/content/docs/workers/examples/websockets.mdx b/src/content/docs/workers/examples/websockets.mdx
index 3035f7c93624d2e..3459a600691be7c 100644
--- a/src/content/docs/workers/examples/websockets.mdx
+++ b/src/content/docs/workers/examples/websockets.mdx
@@ -300,4 +300,4 @@ async function websocket(url) {
 
 ## WebSocket compression
 
-Cloudflare Workers supports WebSocket compression. Refer to [WebSocket Compression](/workers/configuration/compatibility-dates/#websocket-compression) for more information.
\ No newline at end of file
+Cloudflare Workers supports WebSocket compression. Refer to [WebSocket Compression](/workers/configuration/compatibility-flags/#websocket-compression) for more information.
\ No newline at end of file
diff --git a/src/content/docs/workers/languages/python/packages/index.mdx b/src/content/docs/workers/languages/python/packages/index.mdx
index 213d58760ccbf2e..cc2200c9a3c6923 100644
--- a/src/content/docs/workers/languages/python/packages/index.mdx
+++ b/src/content/docs/workers/languages/python/packages/index.mdx
@@ -22,7 +22,7 @@ fastapi
 
 In the example above, you likely noticed that there is no explicit version of the Python package declared in `requirements.txt`.
 
-In Workers, Python package versions are set via [Compatibility Dates](/workers/configuration/compatibility-dates/) and [Compatibility Flags](/workers/configuration/compatibility-dates/#compatibility-flags). Given a particular compatibility date, a specific version of the [Pyodide Python runtime](https://pyodide.org/en/stable/project/changelog.html) is provided to your Worker, providing a specific set of Python packages pinned to specific versions.
+In Workers, Python package versions are set via [Compatibility Dates](/workers/configuration/compatibility-dates/) and [Compatibility Flags](/workers/configuration/compatibility-flags/). Given a particular compatibility date, a specific version of the [Pyodide Python runtime](https://pyodide.org/en/stable/project/changelog.html) is provided to your Worker, providing a specific set of Python packages pinned to specific versions.
 
 As new versions of Pyodide and additional Python packages become available in Workers, we will publish compatibility flags and their associated compatibility dates here on this page.
 
diff --git a/src/content/docs/workers/languages/typescript/index.mdx b/src/content/docs/workers/languages/typescript/index.mdx
index a18d8bbcc19286f..dd8d18872005769 100644
--- a/src/content/docs/workers/languages/typescript/index.mdx
+++ b/src/content/docs/workers/languages/typescript/index.mdx
@@ -17,12 +17,12 @@ TypeScript is a first-class language on Cloudflare Workers. Cloudflare publishes
 ### Generate types that match your Worker's configuration (experimental)
 
 Cloudflare continuously improves [workerd](https://github.com/cloudflare/workerd), the open-source Workers runtime.
-Changes in workerd can introduce JavaScript API changes, thus changing the respective TypeScript types. For example, the [`urlsearchparams_delete_has_value_arg`](/workers/configuration/compatibility-dates/#urlsearchparams-delete-and-has-value-argument) compatibility flag adds optional arguments to some methods, in order to support new additions to the WHATWG URL standard API.
+Changes in workerd can introduce JavaScript API changes, thus changing the respective TypeScript types. For example, the [`urlsearchparams_delete_has_value_arg`](/workers/configuration/compatibility-flags/#urlsearchparams-delete-and-has-value-argument) compatibility flag adds optional arguments to some methods, in order to support new additions to the WHATWG URL standard API.
 
 This means the correct TypeScript types for your Worker depend on:
 
 1. Your Worker's [Compatibility Date](/workers/configuration/compatibility-dates/).
-2. Your Worker's [Compatibility Flags](/workers/configuration/compatibility-dates/#compatibility-flags).
+2. Your Worker's [Compatibility Flags](/workers/configuration/compatibility-flags/).
 
 For example, if you have `compatibility_flags = ["nodejs_als"]` in your `wrangler.toml`, then the runtime will allow you to use the [`AsyncLocalStorage`](https://nodejs.org/api/async_context.html#class-asynclocalstorage) class in your worker code, but you will not see this reflected in the type definitions in `@cloudflare/workers-types`.
 
diff --git a/src/content/docs/workers/platform/changelog/historical-changelog.mdx b/src/content/docs/workers/platform/changelog/historical-changelog.mdx
index baf231a8858cd52..278da58f5bf9d28 100644
--- a/src/content/docs/workers/platform/changelog/historical-changelog.mdx
+++ b/src/content/docs/workers/platform/changelog/historical-changelog.mdx
@@ -136,7 +136,7 @@ This page tracks changes made to Cloudflare Workers before 2023. For a view of m
 
 ## 2022-03-24
 
-* A new compatibility flag has been introduced, `minimal_subrequests` , which removes some features that were unintentionally being applied to same-zone `fetch()` calls. The flag will default to enabled on Tuesday, 2022-04-05, and is described in [Workers `minimal_subrequests` compatibility flag](/workers/configuration/compatibility-dates/#minimal-subrequests).
+* A new compatibility flag has been introduced, `minimal_subrequests` , which removes some features that were unintentionally being applied to same-zone `fetch()` calls. The flag will default to enabled on Tuesday, 2022-04-05, and is described in [Workers `minimal_subrequests` compatibility flag](/workers/configuration/compatibility-flags/#minimal-subrequests).
 * When creating a `Response` with JavaScript-backed ReadableStreams, the `Body` mixin functions (e.g. `await response.text()` ) are now implemented.
 * The `IdentityTransformStream` creates a byte-oriented `TransformStream` implementation that simply passes bytes through unmodified. The readable half of the `TransformStream` supports BYOB-reads. It is important to note that `IdentityTransformStream` is identical to the current non-spec compliant `TransformStream` implementation, which will be updated soon to conform to the WHATWG Stream Standard. All current uses of `new TransformStream()` should be replaced with `new IdentityTransformStream()` to avoid potentially breaking changes later.
 
diff --git a/src/content/docs/workers/platform/changelog/index.mdx b/src/content/docs/workers/platform/changelog/index.mdx
index 45d98c5c5567293..9fa3d86b6fb3220 100644
--- a/src/content/docs/workers/platform/changelog/index.mdx
+++ b/src/content/docs/workers/platform/changelog/index.mdx
@@ -15,7 +15,7 @@ import { ProductChangelog } from "~/components";
 
 This changelog details meaningful changes made to Workers across the Cloudflare dashboard, Wrangler, the API, and the workerd runtime. These changes are not configurable.
 
-This is *different* from [compatibility dates](/workers/configuration/compatibility-dates/) and [compatibility flags](/workers/configuration/compatibility-dates/#compatibility-flags), which let you explicitly opt-in to or opt-out of specific changes to the Workers Runtime.
+This is *different* from [compatibility dates](/workers/configuration/compatibility-dates/) and [compatibility flags](/workers/configuration/compatibility-flags/), which let you explicitly opt-in to or opt-out of specific changes to the Workers Runtime.
 
 {/* <!-- Actual content lives in /src/content/changelogs/workers.yaml. Update the file there for new entries to appear here. For more details, refer to https://developers.cloudflare.com/style-guide/documentation-content-strategy/content-types/changelog/#yaml-file --> */}
 
diff --git a/src/content/docs/workers/runtime-apis/fetch.mdx b/src/content/docs/workers/runtime-apis/fetch.mdx
index b6ac348f5bc5d23..019f4980e5beb59 100644
--- a/src/content/docs/workers/runtime-apis/fetch.mdx
+++ b/src/content/docs/workers/runtime-apis/fetch.mdx
@@ -87,7 +87,7 @@ When making a subrequest with the `fetch()` API, you can specify which forms of
 
 Workers supports both the gzip and brotli compression algorithms. Usually it is not necessary to specify `Accept-Encoding` or `Content-Encoding` headers in the Workers Runtime production environment – brotli or gzip compression is automatically requested when fetching from an origin and applied to the response when returning data to the client, depending on the capabilities of the client and origin server.
 
-To support requesting brotli from the origin, you must enable the [`brotli_content_encoding`](/workers/configuration/compatibility-dates/#brotli-content-encoding-support) compatibility flag in your Worker. Soon, this compatibility flag will be enabled by default for all Workers past an upcoming compatibility date.
+To support requesting brotli from the origin, you must enable the [`brotli_content_encoding`](/workers/configuration/compatibility-flags/#brotli-content-encoding-support) compatibility flag in your Worker. Soon, this compatibility flag will be enabled by default for all Workers past an upcoming compatibility date.
 
 ### Passthrough behavior
 
diff --git a/src/content/docs/workers/runtime-apis/nodejs/index.mdx b/src/content/docs/workers/runtime-apis/nodejs/index.mdx
index 9ea2ad704ba538e..a814d6495cc6364 100644
--- a/src/content/docs/workers/runtime-apis/nodejs/index.mdx
+++ b/src/content/docs/workers/runtime-apis/nodejs/index.mdx
@@ -18,7 +18,7 @@ You can view which APIs are supported using the [Node.js compatability matrix](h
 
 ## Get Started
 
-To enable both built-in runtime APIs and polyfills for your Worker or Pages project, add the [`nodejs_compat`](/workers/configuration/compatibility-dates/#nodejs-compatibility-flag) [compatibility flag](/workers/configuration/compatibility-dates/#nodejs-compatibility-flag) to your `wrangler.toml`, and set your compatibility date to September 23rd, 2024 or later.
+To enable both built-in runtime APIs and polyfills for your Worker or Pages project, add the [`nodejs_compat`](/workers/configuration/compatibility-flags/#nodejs-compatibility-flag) [compatibility flag](/workers/configuration/compatibility-flags/#nodejs-compatibility-flag) to your `wrangler.toml`, and set your compatibility date to September 23rd, 2024 or later.
 
 ```toml title="wrangler.toml"
 compatibility_flags = [ "nodejs_compat" ]
diff --git a/src/content/docs/workers/runtime-apis/rpc/index.mdx b/src/content/docs/workers/runtime-apis/rpc/index.mdx
index 0d77eaefce6f87a..d112d1e34f28807 100644
--- a/src/content/docs/workers/runtime-apis/rpc/index.mdx
+++ b/src/content/docs/workers/runtime-apis/rpc/index.mdx
@@ -10,7 +10,7 @@ description: The built-in, JavaScript-native RPC system built into Workers and
 import { DirectoryListing, Render } from "~/components"
 
 :::note
-To use RPC, [define a compatibility date](/workers/configuration/compatibility-dates) of `2024-04-03` or higher, or include `rpc` in your [compatibility flags](/workers/configuration/compatibility-dates/#nodejs-compatibility-flag).
+To use RPC, [define a compatibility date](/workers/configuration/compatibility-dates) of `2024-04-03` or higher, or include `rpc` in your [compatibility flags](/workers/configuration/compatibility-flags/#nodejs-compatibility-flag).
 :::
 
 Workers provide a built-in, JavaScript-native [RPC (Remote Procedure Call)](https://en.wikipedia.org/wiki/Remote_procedure_call) system, allowing you to:
diff --git a/src/content/docs/workers/runtime-apis/web-standards.mdx b/src/content/docs/workers/runtime-apis/web-standards.mdx
index fdd3ece0f9e4ec0..b8a9560271e0bd5 100644
--- a/src/content/docs/workers/runtime-apis/web-standards.mdx
+++ b/src/content/docs/workers/runtime-apis/web-standards.mdx
@@ -134,7 +134,7 @@ The URL API supports URLs conforming to HTTP and HTTPS schemes.
 
 The default URL class behavior differs from the URL Spec documented above.
 
-A new spec-compliant implementation of the URL class can be enabled using the `url_standard` [compatibility flag](/workers/configuration/compatibility-dates/#compatibility-flags).
+A new spec-compliant implementation of the URL class can be enabled using the `url_standard` [compatibility flag](/workers/configuration/compatibility-flags/).
 
 
 :::
@@ -167,7 +167,7 @@ The `Intl` API allows you to format dates, times, numbers, and more to the forma
 
 ## `navigator.userAgent`
 
-When the [`global_navigator`](/workers/configuration/compatibility-dates/#global-navigator) compatibility flag is set, the [`navigator.userAgent`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/userAgent) property is available with the value `'Cloudflare-Workers'`. This can be used, for example, to reliably determine that code is running within the Workers environment.
+When the [`global_navigator`](/workers/configuration/compatibility-flags/#global-navigator) compatibility flag is set, the [`navigator.userAgent`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/userAgent) property is available with the value `'Cloudflare-Workers'`. This can be used, for example, to reliably determine that code is running within the Workers environment.
 
 ## Unhandled promise rejections
 
@@ -191,7 +191,7 @@ addEventListener('rejectionhandled', (event) => {
 
 ## `navigator.sendBeacon(url[, data])`
 
-When the [`global_navigator`](/workers/configuration/compatibility-dates/#global-navigator) compatibility flag is set, the [`navigator.sendBeacon(...)`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) API is available to send an HTTP `POST` request containing a small amount of data to a web server. This API is intended as a means of transmitting analytics or diagnostics information asynchronously on a best-effort basis.
+When the [`global_navigator`](/workers/configuration/compatibility-flags/#global-navigator) compatibility flag is set, the [`navigator.sendBeacon(...)`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) API is available to send an HTTP `POST` request containing a small amount of data to a web server. This API is intended as a means of transmitting analytics or diagnostics information asynchronously on a best-effort basis.
 
 For example, you can replace:
 
diff --git a/src/content/docs/workers/testing/vitest-integration/configuration.mdx b/src/content/docs/workers/testing/vitest-integration/configuration.mdx
index d534e24f800978d..ad10d50a6e38bb9 100644
--- a/src/content/docs/workers/testing/vitest-integration/configuration.mdx
+++ b/src/content/docs/workers/testing/vitest-integration/configuration.mdx
@@ -145,7 +145,7 @@ The following functions are exported from the `@cloudflare/vitest-pool-workers/c
 
 * `miniflare`: `SourcelessWorkerOptions & { workers?: WorkerOptions\[]; }` optional
 
-  * Use this to provide configuration information that is typically stored within the Wrangler configuration file, such as [bindings](/workers/runtime-apis/bindings/), [compatibility dates](/workers/configuration/compatibility-dates/), and [compatibility flags](/workers/configuration/compatibility-dates/#compatibility-flags). The `WorkerOptions` interface is defined [here](https://github.com/cloudflare/workers-sdk/tree/main/packages/miniflare#interface-workeroptions). Use the `main` option above to configure the entry point, instead of the Miniflare `script`, `scriptPath`, or `modules` options.
+  * Use this to provide configuration information that is typically stored within the Wrangler configuration file, such as [bindings](/workers/runtime-apis/bindings/), [compatibility dates](/workers/configuration/compatibility-dates/), and [compatibility flags](/workers/configuration/compatibility-flags/). The `WorkerOptions` interface is defined [here](https://github.com/cloudflare/workers-sdk/tree/main/packages/miniflare#interface-workeroptions). Use the `main` option above to configure the entry point, instead of the Miniflare `script`, `scriptPath`, or `modules` options.
 
   * If your project makes use of multiple Workers, you can configure auxiliary Workers that run in the same `workerd` process as your tests and can be bound to. Auxiliary Workers are configured using the `workers` array, containing regular Miniflare [`WorkerOptions`](https://github.com/cloudflare/workers-sdk/tree/main/packages/miniflare#interface-workeroptions) objects. Note that unlike the `main` Worker, auxiliary Workers:
     * Cannot have TypeScript entrypoints. You must compile auxiliary Workers to JavaScript first. You can use the [`wrangler deploy --dry-run --outdir dist`](/workers/wrangler/commands/#deploy) command for this.
@@ -166,7 +166,7 @@ The following functions are exported from the `@cloudflare/vitest-pool-workers/c
 :::caution
 
 
-You must define a compatibility date of `2022-10-31` or higher, and include [`nodejs_compat` in your compatibility flags](/workers/configuration/compatibility-dates/#nodejs-compatibility-flag) to use the Workers Vitest integration.
+You must define a compatibility date of `2022-10-31` or higher, and include [`nodejs_compat` in your compatibility flags](/workers/configuration/compatibility-flags/#nodejs-compatibility-flag) to use the Workers Vitest integration.
 
 
 :::
diff --git a/src/content/docs/workers/testing/vitest-integration/isolation-and-concurrency.mdx b/src/content/docs/workers/testing/vitest-integration/isolation-and-concurrency.mdx
index c768525c0f25d62..57def403d33da0f 100644
--- a/src/content/docs/workers/testing/vitest-integration/isolation-and-concurrency.mdx
+++ b/src/content/docs/workers/testing/vitest-integration/isolation-and-concurrency.mdx
@@ -56,7 +56,7 @@ In this model, a single `workerd` process is started with a single Worker for al
 
 Each Worker has its own module cache. As Workers are reused between test runs, their module caches are also reused. Vitest invalidates parts of the module cache at the start of each test run based on changed files.
 
-The Workers Vitest pool works by running code inside a Cloudflare Worker that Vitest would usually run inside a [Node.js worker thread](https://nodejs.org/api/worker_threads.html). To make this possible, the pool requires the [`nodejs_compat`](/workers/configuration/compatibility-dates/#nodejs-compatibility-flag) and [`export_commonjs_default`](/workers/configuration/compatibility-dates/#commonjs-modules-do-not-export-a-module-namespace) compatibility flags to be enabled. The pool also configures `workerd` to use Node-style module resolution and polyfills required `node:*` modules not provided by `nodejs_compat`.
+The Workers Vitest pool works by running code inside a Cloudflare Worker that Vitest would usually run inside a [Node.js worker thread](https://nodejs.org/api/worker_threads.html). To make this possible, the pool requires the [`nodejs_compat`](/workers/configuration/compatibility-flags/#nodejs-compatibility-flag) and [`export_commonjs_default`](/workers/configuration/compatibility-flags/#commonjs-modules-do-not-export-a-module-namespace) compatibility flags to be enabled. The pool also configures `workerd` to use Node-style module resolution and polyfills required `node:*` modules not provided by `nodejs_compat`.
 
 :::caution
 
diff --git a/src/content/partials/workers/nodejs-compat-howto.mdx b/src/content/partials/workers/nodejs-compat-howto.mdx
index 689d325352802e8..12d28124560afbd 100644
--- a/src/content/partials/workers/nodejs-compat-howto.mdx
+++ b/src/content/partials/workers/nodejs-compat-howto.mdx
@@ -6,7 +6,7 @@
 :::caution
 
 
-To use Node.js APIs in your Worker, add the [`nodejs_compat_v2` compatibility flag](/workers/configuration/compatibility-dates/#nodejs-compatibility-flag) to your `wrangler.toml` file.
+To use Node.js APIs in your Worker, add the [`nodejs_compat_v2` compatibility flag](/workers/configuration/compatibility-flags/#nodejs-compatibility-flag) to your `wrangler.toml` file.
 
 
 :::