6 files changed, 7 insertions, 7 deletions

diff --git a/docs/user-guide/02-conventional-features.md b/docs/user-guide/02-conventional-features.md
index 2571712ee..4f381f62f 100644
--- a/docs/user-guide/02-conventional-features.md
+++ b/docs/user-guide/02-conventional-features.md
@@ -521,7 +521,7 @@ Variadic macros are supported by the Slang preprocessor.
 > #### Note ####
 > The use of `#include` in new code is discouraged as this functionality has
 > been superseded by the module system, please refer to
-> [./04-modules-and-access-control.md](./04-modules-and-access-control.md)
+> [Modules and Access Control](04-modules-and-access-control.md)
 
 Attributes
 ----------
diff --git a/docs/user-guide/06-interfaces-generics.md b/docs/user-guide/06-interfaces-generics.md
index 7c957f685..30efbada1 100644
--- a/docs/user-guide/06-interfaces-generics.md
+++ b/docs/user-guide/06-interfaces-generics.md
@@ -852,7 +852,7 @@ void main()
 }
 
 ```
-See  [if-let syntax](03-convenience-features.html#if_let-syntax) for more details.
+See  [if-let syntax](03-convenience-features.md#if_let-syntax) for more details.
 
 
 Generic Interfaces
diff --git a/docs/user-guide/08-compiling.md b/docs/user-guide/08-compiling.md
index 3f895a8c3..132002e90 100644
--- a/docs/user-guide/08-compiling.md
+++ b/docs/user-guide/08-compiling.md
@@ -861,7 +861,7 @@ program->link(linkedProgram.writeRef(), diagnosticBlob.writeRef());
 ```
 
 The linking step is also used to perform link-time specialization, which is a recommended approach for shader specialization
-compared to preprocessor based specialization. Please see [Link-time Specialization and Precompiled Modules](10-link-time-specialization) for more details.
+compared to preprocessor based specialization. Please see [Link-time Specialization and Precompiled Modules](10-link-time-specialization.md) for more details.
 
 Any diagnostic messages related to linking (for example, if an external symbol cannot be resolved) will be written to `diagnosticBlob`.
 
diff --git a/docs/user-guide/09-reflection.md b/docs/user-guide/09-reflection.md
index ad2047a82..1fc48b3d2 100644
--- a/docs/user-guide/09-reflection.md
+++ b/docs/user-guide/09-reflection.md
@@ -21,14 +21,14 @@ Compiling a Program
 -------------------
 
 The first step in reflecting a shader program is, unsurprisingly, to compile it.
-Currently reflection information cannot be queried from code compiled via the command-line `slangc` tool, so applications that want to perform reflection on Slang shader code should use the [compilation API](08-compiling#using-the-compilation-api) to compile a program, and then use `getLayout()` to extract reflection information:
+Currently reflection information cannot be queried from code compiled via the command-line `slangc` tool, so applications that want to perform reflection on Slang shader code should use the [compilation API](08-compiling.md#using-the-compilation-api) to compile a program, and then use `getLayout()` to extract reflection information:
 
 ```c++
 slang::IComponentType* program = ...;
 slang::ProgramLayout* programLayout = program->getLayout(targetIndex);
 ```
 
-For more information, see the [relevant section](08-compiling#layout-and-reflection) of the chapter on compilation.
+For more information, see the [relevant section](08-compiling.md#layout-and-reflection) of the chapter on compilation.
 
 Types and Variables
 -------------------
diff --git a/docs/user-guide/10-link-time-specialization.md b/docs/user-guide/10-link-time-specialization.md
index eba29076f..b08ef1f0d 100644
--- a/docs/user-guide/10-link-time-specialization.md
+++ b/docs/user-guide/10-link-time-specialization.md
@@ -22,7 +22,7 @@ While functioning systems can be built around preprocessor macros, overusing the
 Slang approaches the problem of shader specialization by supporting generics as a first class feature that allow most specializable code to be
 written in strongly typed code, and by allowing specialization to be triggered through link-time constants or types.
 
-As discussed in the [Compiling code with Slang](compiling) chapter, Slang provides a three-step compilation model: precompiling, linking and target code generation.
+As discussed in the [Compiling code with Slang](08-compiling.md) chapter, Slang provides a three-step compilation model: precompiling, linking and target code generation.
 Assuming the user shader is implemented as three Slang modules: `a.slang`, `b.slang`, and `c.slang`, the user can precompile all three modules to binary IR and store
 them as `a.slang-module`, `b.slang-module`, and `c.slang-module` in a complete offline process that is independent to any specialization arguments.
 Next, these three IR modules are linked together to form a self-contained program that will then go through a set of compiler optimizations for target code generation.
diff --git a/docs/user-guide/a2-01-spirv-target-specific.md b/docs/user-guide/a2-01-spirv-target-specific.md
index 7686f7312..05bf023df 100644
--- a/docs/user-guide/a2-01-spirv-target-specific.md
+++ b/docs/user-guide/a2-01-spirv-target-specific.md
@@ -287,7 +287,7 @@ To generate a valid SPIR-V with multiple entry points, use `-fvk-use-entrypoint-
 Global memory pointers
 ------------------------------
 
-Slang supports global memory pointers when targeting SPIRV. See [an example and explanation](03-convenience-features.html#pointers-limited).
+Slang supports global memory pointers when targeting SPIRV. See [an example and explanation](03-convenience-features.md#pointers-limited).
 
 `float4*` in user code will be translated to a pointer in PhysicalStorageBuffer storage class in SPIRV.
 When a slang module uses a pointer type, the resulting SPIRV will be using the SpvAddressingModelPhysicalStorageBuffer64 addressing mode. Modules without use of pointers will use SpvAddressingModelLogical addressing mode.