diff --git a/build_overview.md b/build_overview.md
index b1514231cb661d9b279d94a06a8d1a94698822c6..ea0069ec9b0084dd8c1d1d5e47a8bf86556c70f9 100644
--- a/build_overview.md
+++ b/build_overview.md
@@ -117,13 +117,13 @@ $ dot -Tpng tree.dot -o tree.png
 ### Inspecting the content of a GN target
 
 ```bash
-$ buildtools/gn desc out/debug-x86 //path/to/my:target
+$ buildtools/gn desc out/debug-x64 //path/to/my:target
 ```
 
 ### Finding references to a GN target
 
 ```bash
-$ buildtools/gn refs out/debug-x86 //path/to/my:target
+$ buildtools/gn refs out/debug-x64 //path/to/my:target
 ```
 
 ### Referencing targets for the build host
@@ -146,7 +146,7 @@ file:
 If a target is defined in a GN build file as `//foo/bar/blah:dash`, that target
 (and its dependencies) can be built with:
 ```bash
-$ buildtools/ninja -C out/debug-x86 -j64 foo/bar/blah:dash
+$ buildtools/ninja -C out/debug-x64 -j64 foo/bar/blah:dash
 ```
 Note that this only works for targets in the default toolchain.
 
@@ -161,7 +161,7 @@ $ buildtools/gn help ninja_rules
 You can also browse the set of Ninja targets currently defined in your output
 directory with:
 ```bash
-$ buildtools/ninja -C out/debug-x86 -t browse
+$ buildtools/ninja -C out/debug-x64 -t browse
 ```
 Note that the presence of a Ninja target does not mean it will be built - for
 that it needs to depend on the “default” target.
diff --git a/build_variants.md b/build_variants.md
index 8df384bc5227abe9ec756ecf1fb815644c2cc7b9..5c7a48e5b1d276502bcb03ab6bc46598e1c2bbeb 100644
--- a/build_variants.md
+++ b/build_variants.md
@@ -27,7 +27,7 @@ Here's an example running `gen.py` directly:
 This does the same thing using the `fx set` tool:
 
 ```sh
-fx set x86 --variant host_asan --variant asan=cat,ledger
+fx set x64 --variant host_asan --variant asan=cat,ledger
 ```
 
  1. The first switch applies the `host_asan` matching rule, which enables
@@ -53,9 +53,9 @@ set the `select_variant` GN build argument directly.
    approximate what you want and then edit the `select_variant` value `gen.py`
    produces:
    * You can just edit the `args.gn` file in the GN output directory
-     (e.g. `out/debug-x86/args.gn`) and the next `ninja` run (aka `fx build`)
+     (e.g. `out/debug-x64/args.gn`) and the next `ninja` run (aka `fx build`)
      will re-run `gn gen` with those changes.
-   * You can use the command `./buildtools gn args out/debug-x86`, which
+   * You can use the command `./buildtools gn args out/debug-x64`, which
      will run your `$EDITOR` on the `args.gn` file and then do `gn gen`
      immediately so you can see any errors in your GN syntax.
 
@@ -71,7 +71,7 @@ also runs GN this way:
 You can also use the `fx set` tool to run `gen.py` for you:
 
 ```sh
-fx set x86 --help-args select_variant
+fx set x64 --help-args select_variant
 ```
 
 If you combine this with one or more `--variant` switches, GN will show you
@@ -84,7 +84,7 @@ the actual value of `select_variant` that `gen.py` chose.  For example:
 or:
 
 ```sh
-fx set x86 --help-args select_variant --variant asan=cat,ledger
+fx set x64 --help-args select_variant --variant asan=cat,ledger
 ```
 
 prints out:
diff --git a/ctu_analysis.md b/ctu_analysis.md
index a37cad6dba833d33dd0b0e1e39b6a0e7c04c1c80..4c718f85e05544eb3eca50982f0670a4eab595a8 100644
--- a/ctu_analysis.md
+++ b/ctu_analysis.md
@@ -75,7 +75,7 @@ make clean && ./run.sh
 In order to build only the kernel, specify a `TARGET` as an environment variable:
 
 ```
-make clean && TARGET=./build-zircon-pc-x86/zircon.elf ./run.sh
+make clean && TARGET=./build-zircon-pc-x64/zircon.elf ./run.sh
 ```
 
 The script also requires [clangify.py](https://gist.github.com/karkhaz/2ab5e8c7a8783318d44ceca715f20438) to be in the zircon directory with executable bit set. After the analysis has finished, there will be a `.result-xtu` directory, containing:
diff --git a/debugging.md b/debugging.md
index 84f8a57c8d3d1f6fd8071b5788db90a177ea770f..c4aceb3ffbda59787d81d308644b25a7f2f7f09c 100644
--- a/debugging.md
+++ b/debugging.md
@@ -72,7 +72,7 @@ addresses in the backtrace to symbolic form. This program is `symbolize`:
 Copy the above to a file, say `backtrace.out`, and then run:
 
 ```
-bash$ ZIRCON_BUILD_DIR=$FUCHSIA_DIR/out/build-zircon/build-x86
+bash$ ZIRCON_BUILD_DIR=$FUCHSIA_DIR/out/build-zircon/build-x64
 bash$ cat backtrace.out | $FUCHSIA_DIR/zircon/scripts/symbolize \
   --build-dir=$ZIRCON_BUILD_DIR \
   $ZIRCON_BUILD_DIR/system/utest/debugger/debugger.elf
diff --git a/development/languages/dart/ides.md b/development/languages/dart/ides.md
index f224f01d28422a5123062c71a32e7f493ee4263b..c86401f32e61285949ba6c245b24493dd0654fd1 100644
--- a/development/languages/dart/ides.md
+++ b/development/languages/dart/ides.md
@@ -52,5 +52,5 @@ following:
   build. This means that if you have a broken release build, any release build
   overrides a debug build. With a broken release build, no amount of correct
   rebuilding on debug will solve the issue until you delete
-  `//out/release-x86`.
+  `//out/release-x64`.
 - Delete the .packages file in your project and rebuild.
diff --git a/development/languages/rust/README.md b/development/languages/rust/README.md
index 2e1decae940bafc01c59052c6d9ad3097ce948a8..6de8c60d467aa20430abbf3b9e466eba7d0f427e 100644
--- a/development/languages/rust/README.md
+++ b/development/languages/rust/README.md
@@ -116,7 +116,7 @@ If you want to test out Fuchsia with your own custom-built versions of rustc or
 you can set the `rustc_prefix` argument to `fx set`, like this:
 
 ```
-fx set x86 --release --args "rustc_prefix=\"/path/to/bin/dir\""
+fx set x64 --release --args "rustc_prefix=\"/path/to/bin/dir\""
 ```
 
 ## Going further
diff --git a/development/languages/rust/third_party.md b/development/languages/rust/third_party.md
index 499ade0a9e3233d2421164fd98e354020961b781..92a883d78d71a3bbb94eaee8a7df6fd8bf3360aa 100644
--- a/development/languages/rust/third_party.md
+++ b/development/languages/rust/third_party.md
@@ -28,7 +28,7 @@ a new crate, you'll need to either run `update_rust_crates.sh` or temporarily
 pass use_frozen_with_cargo=false to gn. If you are using the fx scripts,
 you can do so as follows:
 
-    ./scripts/fx set x86 --release --packages garnet/packages/default --args "use_frozen_with_cargo=false"
+    ./scripts/fx set x64 --release --packages garnet/packages/default --args "use_frozen_with_cargo=false"
 
 Running `update_rust_crates.sh` to solve this problem will have the side effect
 of updating all the existing crates in `third_party/rust-crates`, which may not be desired.
diff --git a/fuchsia_paver.md b/fuchsia_paver.md
index feed33e97c26c94806cec2db40050ff1271d8e3e..514db37f180149cd924d3c23ea8ded9bead126ab 100644
--- a/fuchsia_paver.md
+++ b/fuchsia_paver.md
@@ -23,7 +23,7 @@ extend to allow you to build what you need.
 ## TL;DR
 
 Read this all before? Here are the common case commands
-1. `fx set x86`
+1. `fx set x64`
 2. `fx full-build`
 3. Make the install media
     * [[ insert USB drive into host ]]
@@ -37,7 +37,7 @@ Read this all before? Here are the common case commands
 Detailed instructions for obtaining and building Fuchsia are available from the
 [Getting Started](getting_started.md) guide, but we'll assume here that the
 target system is x86-based and that you want to build a complete system. To
-configure our build for this we can run `fx set x86` and then build with
+configure our build for this we can run `fx set x64` and then build with
 `fx full-build`.
 
 ## Creating install media
diff --git a/getting_started.md b/getting_started.md
index 9f378d20d683429f4485bc5eb2d98409f94d8a67..816b395e9acac6f8212c8c79f7152ad80fbd55e5 100644
--- a/getting_started.md
+++ b/getting_started.md
@@ -67,13 +67,13 @@ the `fx` command should already be in your path. If not, the command is also
 available as `scripts/fx`.
 
 ```
-fx set x86
+fx set x64
 fx full-build
 ```
 
 The first command selects the build configuration you wish to build and
 generates the build system itself in an output directory
-(e.g., `out/debug-x86`).
+(e.g., `out/debug-x64`).
 
 The second command actually executes the build, transforming the source code in
 build products. If you modify the source tree, you can do an incremental build
@@ -83,15 +83,15 @@ Alternatively, you can use the [underlying build system directly](build_system.m
 
 #### [optional] Customize Build Environment
 
-By default you will get a x86 debug build. You can skip this section unless
+By default you will get a x64 debug build. You can skip this section unless
 you want something else.
 
 Run `fset-usage` to see a list of build options. Some examples:
 
 ```
-fx set x86                 # x86 debug build
+fx set x64                 # x64 debug build
 fx set arm64               # arm64 debug build
-fx set x86 --release       # x86 release build
+fx set x64 --release       # x64 release build
 ```
 
 #### [optional] Accelerate builds with `ccache` and `goma`
diff --git a/toolchain.md b/toolchain.md
index 1b58305d335306d85a3fc21edb98b8a2698a93c1..65fa5a15a0a9604a7b74ba7cdaa4a4b0302439bb 100644
--- a/toolchain.md
+++ b/toolchain.md
@@ -29,15 +29,15 @@ LLVM_SRCDIR=${HOME}/llvm
 Before building the runtime libraries that are built along with the
 compiler, you need a Zircon `sysroot` built.  This comes from the
 Zircon build and sits in the `sysroot` subdirectory of the main Zircon
-build directory.  For example, `.../build-x86/sysroot`.
+build directory.  For example, `.../build-x64/sysroot`.
 In the following commands, the string `${FUCHSIA_${arch}_SYSROOT}`
 stands in for this absolute directory name.  You can cut & paste these
 commands into a shell after setting the `FUCHSIA_${arch}_SYSROOT`
 variable, e.g.:
 
 ```bash
-make x86
-FUCHSIA_x86_64_SYSROOT=`pwd`/build-x86/sysroot
+make x64
+FUCHSIA_x86_64_SYSROOT=`pwd`/build-x64/sysroot
 
 make arm64
 FUCHSIA_aarch64_SYSROOT=`pwd`/build-arm64/sysroot