diff --git a/about/faq.rst b/about/faq.rst
index 4f13dd46be78..4534e5025591 100644
--- a/about/faq.rst
+++ b/about/faq.rst
@@ -290,7 +290,7 @@ While Vulkan and OpenGL remain our primary focus for their open standard and
 cross-platform benefits, Godot 4.3 introduced experimental support for Direct3D 12.
 This addition aims to enhance performance and compatibility on platforms where
 Direct3D 12 is prevalent, such as Windows and Xbox. However, Vulkan and OpenGL
-will continue as the default rendering backends on all platforms, including Windows.
+will continue as the default rendering drivers on all platforms, including Windows.
 
 Why does Godot aim to keep its core feature set small?
 ------------------------------------------------------
diff --git a/about/list_of_features.rst b/about/list_of_features.rst
index a9e55ed9e279..86336548c7b2 100644
--- a/about/list_of_features.rst
+++ b/about/list_of_features.rst
@@ -95,17 +95,18 @@ Editor
 Rendering
 ---------
 
-3 rendering *methods* (running over 2 rendering *drivers*) are available:
-
-- **Forward+**, running over Vulkan 1.0 (with optional Vulkan 1.1 and 1.2
-  features). The most advanced graphics backend, suited for desktop platforms
-  only. Used by default on desktop platforms.
-- **Forward Mobile**, running over Vulkan 1.0 (with optional Vulkan 1.1 and 1.2
-  features). Less features, but renders simple scenes faster. Suited for mobile
-  and desktop platforms. Used by default on mobile platforms.
-- **Compatibility**, running over OpenGL 3.3 / OpenGL ES 3.0 / WebGL 2.0. The least
-  advanced graphics backend, suited for low-end desktop and mobile platforms.
-  Used by default on the web platform.
+Godot 4 includes three renderers:
+
+- **Forward+**. The most advanced renderer, suited for desktop platforms only.
+  Used by default on desktop platforms. This renderer uses **Vulkan**, **Direct3D 12**,
+  or **Metal** as the rendering driver, and it uses the **RenderingDevice** backend.
+- **Mobile**. Fewer features, but renders simple scenes faster. Suited for mobile
+  and desktop platforms. Used by default on mobile platforms. This renderer uses
+  **Vulkan**, **Direct3D 12**, or **Metal** as the rendering driver, and it uses
+  the **RenderingDevice** backend.
+- **Compatibility**, sometimes called **GL Compatibility**. The least advanced
+  renderer, suited for low-end desktop and mobile platforms. Used by default on
+  the web platform. This renderer uses **OpenGL** as the rendering driver.
 
 See :ref:`doc_renderers` for a detailed comparison of the rendering methods.
 
@@ -188,9 +189,9 @@ See :ref:`doc_renderers` for a detailed comparison of the rendering methods.
 
 - HDR rendering with sRGB.
 - Perspective, orthographic and frustum-offset cameras.
-- When using the Forward+ backend, a depth prepass is used to improve
+- When using the Forward+ renderer, a depth prepass is used to improve
   performance in complex scenes by reducing the cost of overdraw.
-- :ref:`doc_variable_rate_shading` on supported GPUs in Forward+ and Forward Mobile.
+- :ref:`doc_variable_rate_shading` on supported GPUs in Forward+ and Mobile.
 
 **Physically-based rendering (built-in material features):**
 
@@ -217,10 +218,10 @@ See :ref:`doc_renderers` for a detailed comparison of the rendering methods.
 - Specular, indirect light, and volumetric fog energy can be adjusted on a per-light basis.
 - Adjustable light "size" for fake area lights (will also make shadows blurrier).
 - Optional distance fade system to fade distant lights and their shadows, improving performance.
-- When using the Forward+ backend (default on desktop), lights are
+- When using the Forward+ renderer (default on desktop), lights are
   rendered with clustered forward optimizations to decrease their individual cost.
   Clustered rendering also lifts any limits on the number of lights that can be used on a mesh.
-- When using the Forward Mobile backend, up to 8 omni lights and 8 spot lights can
+- When using the Mobile renderer, up to 8 omni lights and 8 spot lights can
   be displayed per mesh resource. Baked lighting can be used to overcome this limit
   if needed.
 
@@ -276,10 +277,10 @@ See :ref:`doc_renderers` for a detailed comparison of the rendering methods.
   Parallax box correction can optionally be enabled.
 - Screen-space reflections with support for material roughness.
 - Reflection techniques can be mixed together for greater accuracy or scalability.
-- When using the Forward+ backend (default on desktop), reflection probes are
+- When using the Forward+ renderer (default on desktop), reflection probes are
   rendered with clustered forward optimizations to decrease their individual cost.
   Clustered rendering also lifts any limits on the number of reflection probes that can be used on a mesh.
-- When using the Forward Mobile backend, up to 8 reflection probes can be displayed per mesh
+- When using the Mobile renderer, up to 8 reflection probes can be displayed per mesh
   resource. When using the Compatibility renderer, up to 2 reflection probes can
   be displayed per mesh resource.
 
@@ -294,10 +295,10 @@ See :ref:`doc_renderers` for a detailed comparison of the rendering methods.
   complex skinned meshes with no performance penalty, even if the decal moves every frame.
 - Support for nearest, bilinear, trilinear or anisotropic texture filtering (configured globally).
 - Optional distance fade system to fade distant decals, improving performance.
-- When using the Forward+ backend (default on desktop), decals are
+- When using the Forward+ renderer (default on desktop), decals are
   rendered with clustered forward optimizations to decrease their individual cost.
   Clustered rendering also lifts any limits on the number of decals that can be used on a mesh.
-- When using the Forward Mobile backend, up to 8 decals can be displayed per mesh
+- When using the Mobile renderer, up to 8 decals can be displayed per mesh
   resource.
 
 **Sky:**
diff --git a/contributing/development/core_and_modules/custom_platform_ports.rst b/contributing/development/core_and_modules/custom_platform_ports.rst
index 80a1e09a8fe5..ccce15b8ccc6 100644
--- a/contributing/development/core_and_modules/custom_platform_ports.rst
+++ b/contributing/development/core_and_modules/custom_platform_ports.rst
@@ -51,7 +51,7 @@ The official platform ports can be used as a reference when creating a custom pl
 
 While platform code is usually self-contained, there are exceptions to this
 rule. For instance, audio drivers that are shared across several platforms and
-rendering backends are located in the
+rendering drivers are located in the
 `drivers/ folder <https://github.com/godotengine/godot/tree/master/drivers>`__
 of the Godot source code.
 
@@ -183,7 +183,7 @@ clone's ``platform/`` folder, then run ``scons platform=<name>``. No other steps
 necessary for building, unless third-party platform-specific dependencies need
 to be installed first.
 
-However, when a custom rendering backend is needed, another folder must be added
+However, when a custom rendering driver is needed, another folder must be added
 in ``drivers/``. In this case, the platform port can be distributed as a fork of
 the Godot repository, or as a collection of several folders that can be added
 over a Godot Git repository clone.
diff --git a/contributing/development/core_and_modules/internal_rendering_architecture.rst b/contributing/development/core_and_modules/internal_rendering_architecture.rst
index b2c8e0b791d1..1dd7402106fd 100644
--- a/contributing/development/core_and_modules/internal_rendering_architecture.rst
+++ b/contributing/development/core_and_modules/internal_rendering_architecture.rst
@@ -44,10 +44,11 @@ affect that pixel.
 This approach can greatly speed up rendering performance on desktop hardware,
 but is substantially less efficient on mobile.
 
-Forward Mobile
-^^^^^^^^^^^^^^
+Mobile
+^^^^^^
 
 This is a forward renderer that uses a traditional single-pass approach to lighting.
+Internally, it is called **Forward Mobile**.
 
 Intended for mobile platforms, but can also run on desktop platforms. This
 rendering method is optimized to perform well on mobile GPUs. Mobile GPUs have a
@@ -92,7 +93,7 @@ features result in a notable performance penalty.
 
 On desktop platforms, the use of sub-passes won't have any impact on
 performance. However, this rendering method can still perform better than
-Clustered Forward in simple scenes thanks to its lower complexity and lower
+Forward+ in simple scenes thanks to its lower complexity and lower
 bandwidth usage. This is especially noticeable on low-end GPUs, integrated
 graphics or in VR applications.
 
@@ -110,11 +111,11 @@ Compatibility
     This is the only rendering method available when using the OpenGL driver.
     This rendering method is not available when using Vulkan or Direct3D 12.
 
-This is a traditional (non-clustered) forward renderer. It's intended for old
-GPUs that don't have Vulkan support, but still works very efficiently on newer
-hardware. Specifically, it is optimized for older and lower-end mobile devices
-However, many optimizations carry over making it a good choice for older and
-lower-end desktop as well.
+This is a traditional (non-clustered) forward renderer. Internally, it is called
+**GL Compatibility**. It's intended for old GPUs that don't have Vulkan support,
+but still works very efficiently on newer hardware. Specifically, it is optimized
+for older and lower-end mobile devices. However, many optimizations carry over
+making it a good choice for older and lower-end desktop as well.
 
 Like the Mobile renderer, the Compatibility renderer uses an R10G10B10A2 UNORM
 texture for 3D rendering. Unlike the mobile renderer, colors are tonemapped and
@@ -134,7 +135,7 @@ looks and needs to be kept in mind when designing scenes for the Compatibility
 renderer.
 
 Given its low-end focus, this rendering method does not provide high-end
-rendering features (even less so compared to Forward Mobile). Most
+rendering features (even less so compared to Mobile). Most
 post-processing effects are not available.
 
 Why not deferred rendering?
@@ -248,11 +249,11 @@ Summary of rendering drivers/methods
 The following rendering API + rendering method combinations are currently possible:
 
 - Vulkan + Forward+
-- Vulkan + Forward Mobile
+- Vulkan + Mobile
 - Direct3D 12 + Forward+
-- Direct3D 12 + Forward Mobile
+- Direct3D 12 + Mobile
 - Metal + Forward+ (via MoltenVK)
-- Metal + Forward Mobile (via MoltenVK)
+- Metal + Mobile (via MoltenVK)
 - OpenGL + Compatibility
 
 Each combination has its own limitations and performance characteristics. Make
@@ -350,14 +351,14 @@ this.
 **Core GLSL material shaders:**
 
 - Forward+: `servers/rendering/renderer_rd/shaders/forward_clustered/scene_forward_clustered.glsl <https://github.com/godotengine/godot/blob/4.2/servers/rendering/renderer_rd/shaders/forward_clustered/scene_forward_clustered.glsl>`__
-- Forward Mobile: `servers/rendering/renderer_rd/shaders/forward_mobile/scene_forward_mobile.glsl <https://github.com/godotengine/godot/blob/4.2/servers/rendering/renderer_rd/shaders/forward_mobile/scene_forward_mobile.glsl>`__
+- Mobile: `servers/rendering/renderer_rd/shaders/forward_mobile/scene_forward_mobile.glsl <https://github.com/godotengine/godot/blob/4.2/servers/rendering/renderer_rd/shaders/forward_mobile/scene_forward_mobile.glsl>`__
 - Compatibility: `drivers/gles3/shaders/scene.glsl <https://github.com/godotengine/godot/blob/4.2/drivers/gles3/shaders/scene.glsl>`__
 
 **Material shader generation:**
 
 - `scene/resources/material.cpp <https://github.com/godotengine/godot/blob/4.2/scene/resources/material.cpp>`__
 
-**Other GLSL shaders for Forward+ and Forward Mobile rendering methods:**
+**Other GLSL shaders for Forward+ and Mobile rendering methods:**
 
 - `servers/rendering/renderer_rd/shaders/ <https://github.com/godotengine/godot/blob/4.2/servers/rendering/renderer_rd/shaders/>`__
 - `modules/lightmapper_rd/ <https://github.com/godotengine/godot/blob/4.2/modules/lightmapper_rd>`__
@@ -371,9 +372,9 @@ this.
 
 .. note::
 
-    The following is only applicable in the Forward+ and Forward Mobile
+    The following is only applicable in the Forward+ and Mobile
     rendering methods, not in Compatibility. Multiple Viewports can be used to
-    emulate this when using the Compatibility backend, or to perform 2D
+    emulate this when using the Compatibility renderer, or to perform 2D
     resolution scaling.
 
 2D and 3D are rendered to separate buffers, as 2D rendering in Godot is performed
@@ -416,7 +417,7 @@ with large amounts of lights.
 The Forward+ and Mobile rendering methods don't feature 2D batching yet, but
 it's planned for a future release.
 
-The Compatibility backend features 2D batching to improve performance, which is
+The Compatibility renderer features 2D batching to improve performance, which is
 especially noticeable with lots of text on screen.
 
 MSAA can be enabled in 2D to provide "automatic" line and polygon antialiasing,
@@ -440,7 +441,7 @@ used to calculate particle collisions in 2D.
 Batching and instancing
 ^^^^^^^^^^^^^^^^^^^^^^^
 
-In the Forward+ backend, Vulkan instancing is used to group rendering
+In the Forward+ renderer, Vulkan instancing is used to group rendering
 of identical objects for performance. This is not as fast as static mesh
 merging, but it still allows instances to be culled individually.
 
@@ -449,10 +450,9 @@ Light, decal and reflection probe rendering
 
 .. note::
 
-  Reflection probe and decal rendering are currently not available in the
-  Compatibility backend.
+  Decal rendering is currently not available in the Compatibility renderer.
 
-As its name implies, the Forward+ backend uses clustered lighting. This
+The Forward+ renderer uses clustered lighting. This
 allows using as many lights as you want; performance largely depends on screen
 coverage. Shadow-less lights can be almost free if they don't occupy much space
 on screen.
@@ -461,12 +461,12 @@ All rendering methods also support rendering up to 8 directional lights at the
 same time (albeit with lower shadow quality when more than one light has shadows
 enabled).
 
-The Forward Mobile backend uses a single-pass lighting approach, with a
+The Mobile renderer uses a single-pass lighting approach, with a
 limitation of 8 OmniLights + 8 SpotLights affecting each Mesh *resource* (plus a
 limitation of 256 OmniLights + 256 SpotLights in the camera view). These limits
 are hardcoded and can't be adjusted in the project settings.
 
-The Compatibility backend uses a hybrid single-pass + multi-pass lighting
+The Compatibility renderer uses a hybrid single-pass + multi-pass lighting
 approach. Lights without shadows are rendered in a single pass. Lights with
 shadows are rendered in multiple passes. This is required for performance
 reasons on mobile devices. As a result, performance does not scale well with
@@ -483,34 +483,34 @@ separate static shadow rendering from dynamic shadow rendering, but this is
 planned in a future release.
 
 Clustering is also used for reflection probes and decal rendering in the
-Forward+ backend.
+Forward+ renderer.
 
 Shadow mapping
 ^^^^^^^^^^^^^^
 
-Both Forward+ and Forward Mobile methods use
+Both Forward+ and Mobile methods use
 :abbr:`PCF (Percentage Closer Filtering)` to filter shadow maps and create a
 soft penumbra. Instead of using a fixed PCF pattern, these methods use a vogel
 disk pattern which allows for changing the number of samples and smoothly
 changing the quality.
 
 Godot also supports percentage-closer soft shadows (PCSS) for more realistic
-shadow penumbra rendering. PCSS shadows are limited to the Forward+
-backend as they're too demanding to be usable in the Forward Mobile backend.
+shadow penumbra rendering. PCSS shadows are limited to the Forward+ renderer
+as they're too demanding to be usable in the Mobile renderer.
 PCSS also uses a vogel-disk shaped kernel.
 
 Additionally, both shadow-mapping techniques rotate the kernel on a per-pixel
 basis to help soften under-sampling artifacts.
 
-The Compatibility backend doesn't support shadow mapping for any light types yet.
+The Compatibility renderer supports shadow mapping for DirectionalLight3D,
+OmniLight3D, and SpotLight3D lights.
 
 Temporal antialiasing
 ^^^^^^^^^^^^^^^^^^^^^
 
 .. note::
 
-    Only available in the Forward+ backend, not the Forward Mobile or
-    Compatibility methods.
+    Only available in the Forward+ renderer, not the Mobile or Compatibility renderers.
 
 Godot uses a custom TAA implementation based on the old TAA implementation from
 `Spartan Engine <https://github.com/PanosK92/SpartanEngine>`__.
@@ -542,13 +542,12 @@ Global illumination
 
 .. note::
 
-    VoxelGI and SDFGI are only available in the Forward+ backend, not the
-    Forward Mobile or Compatibility methods.
+    VoxelGI and SDFGI are only available in the Forward+ renderer, not the
+    Mobile or Compatibility renderers.
 
-    LightmapGI *baking* is only available in the Forward+ and Forward Mobile
-    methods, and can only be performed within the editor (not in an exported
-    project). LightmapGI *rendering* will eventually be supported by the
-    Compatibility backend.
+    LightmapGI *baking* is only available in the Forward+ and Mobile renderers,
+    and can only be performed within the editor (not in an exported
+    project). LightmapGI *rendering* is supported by the Compatibility renderer.
 
 Godot supports voxel-based GI (VoxelGI), signed distance field GI (SDFGI) and
 lightmap baking and rendering (LightmapGI). These techniques can be used
@@ -558,7 +557,7 @@ Lightmap baking happens on the GPU using Vulkan compute shaders. The GPU-based
 lightmapper is implemented in the LightmapperRD class, which inherits from the
 Lightmapper class. This allows for implementing additional lightmappers, paving
 the way for a future port of the CPU-based lightmapper present in Godot 3.x.
-This would allow baking lightmaps while using the Compatibility backend.
+This would allow baking lightmaps while using the Compatibility renderer.
 
 **Core GI C++ code:**
 
@@ -594,14 +593,13 @@ Depth of field
 
 .. note::
 
-    Only available in the Forward+ and Forward Mobile methods, not the
-    Compatibility backend.
+    Only available in the Forward+ and Mobile renderers, not the
+    Compatibility renderer.
 
-The Forward+ and Forward Mobile methods use different approaches to
-DOF rendering, with different visual results. This is done to best
-match the performance characteristics of the target hardware. In Clustered
-Forward, DOF is performed using a compute shader. In Forward Mobile, DOF is
-performed using a fragment shader (raster).
+The Forward+ and Mobile renderers use different approaches to DOF rendering, with
+different visual results. This is done to best match the performance characteristics
+of the target hardware. In Forward+, DOF is performed using a compute shader. In
+Mobile, DOF is performed using a fragment shader (raster).
 
 Box, hexagon and circle bokeh shapes are available (from fastest to slowest).
 Depth of field can optionally be jittered every frame to improve its appearance
@@ -615,7 +613,7 @@ when temporal antialiasing is enabled.
 
 - `servers/rendering/renderer_rd/shaders/effects/bokeh_dof.glsl <https://github.com/godotengine/godot/blob/4.2/servers/rendering/renderer_rd/shaders/effects/bokeh_dof.glsl>`__
 
-**Depth of field GLSL shader (raster - used for Forward Mobile):**
+**Depth of field GLSL shader (raster - used for Mobile):**
 
 - `servers/rendering/renderer_rd/shaders/effects/bokeh_dof_raster.glsl <https://github.com/godotengine/godot/blob/4.2/servers/rendering/renderer_rd/shaders/effects/bokeh_dof_raster.glsl>`__
 
@@ -624,10 +622,9 @@ Screen-space effects (SSAO, SSIL, SSR, SSS)
 
 .. note::
 
-    Only available in the Forward+ backend, not the Forward Mobile or
-    Compatibility methods.
+    Only available in the Forward+ renderer, not the Mobile or Compatibility renderers.
 
-The Forward+ backend supports screen-space ambient occlusion,
+The Forward+ renderer supports screen-space ambient occlusion,
 screen-space indirect lighting, screen-space reflections and subsurface scattering.
 
 SSAO uses an implementation derived from Intel's
@@ -701,8 +698,7 @@ Volumetric fog
 
 .. note::
 
-    Only available in the Forward+ backend, not the Forward Mobile or
-    Compatibility methods.
+    Only available in the Forward+ renderer, not the Mobile or Compatibility renderers.
 
 .. seealso::
 
diff --git a/tutorials/3d/3d_rendering_limitations.rst b/tutorials/3d/3d_rendering_limitations.rst
index 0c144592e839..34cbd850559c 100644
--- a/tutorials/3d/3d_rendering_limitations.rst
+++ b/tutorials/3d/3d_rendering_limitations.rst
@@ -33,12 +33,12 @@ without affecting the source file.
 Color banding
 -------------
 
-When using the Forward+ or Forward Mobile rendering methods, Godot's 3D engine
+When using the Forward+ or Mobile rendering methods, Godot's 3D engine
 renders internally in HDR. However, the rendering output will be tonemapped to a
 low dynamic range so it can be displayed on the screen. This can result in
 visible banding, especially when using untextured materials. For performance
-reasons, color precision is also lower when using the Forward Mobile rendering
-method compared to Forward+.
+reasons, color precision is also lower when using the Mobile rendering method
+compared to Forward+.
 
 When using the Compatibility rendering method, HDR is not used and the color
 precision is the lowest of all rendering methods. This also applies to 2D
@@ -46,8 +46,8 @@ rendering, where banding may be visible when using smooth gradient textures.
 
 There are two main ways to alleviate banding:
 
-- If using the Forward+ or Forward Mobile rendering methods, enable **Use
-  Debanding** in the advanced Project Settings. This applies a fullscreen debanding
+- If using the Forward+ or Mobile rendering methods, enable **Use Debanding** in
+  the advanced Project Settings. This applies a fullscreen debanding
   shader as a post-processing effect and is very cheap.
 - Alternatively, bake some noise into your textures. This is mainly effective in
   2D, e.g. for vignetting effects. In 3D, you can also use a `custom debanding
diff --git a/tutorials/3d/environment_and_post_processing.rst b/tutorials/3d/environment_and_post_processing.rst
index cacc178e0b80..de3dc526eee5 100644
--- a/tutorials/3d/environment_and_post_processing.rst
+++ b/tutorials/3d/environment_and_post_processing.rst
@@ -371,7 +371,7 @@ The Environment resource supports many popular mid- and post-processing effects.
 Screen-Space Reflections (SSR)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-*This feature is only available when using the Forward+ backend, not
+*This feature is only available when using the Forward+ renderer, not
 Mobile or Compatibility.*
 
 While Godot supports several sources of reflection data such as
@@ -413,7 +413,7 @@ uniforms.
 Screen-Space Ambient Occlusion (SSAO)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-*This feature is only available when using the Forward+ backend, not
+*This feature is only available when using the Forward+ renderer, not
 Mobile or Compatibility.*
 
 As mentioned in the **Ambient** section, areas where light from light nodes
@@ -487,7 +487,7 @@ parameters:
 Screen-Space Indirect Lighting (SSIL)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-*This feature is only available when using the Forward+ backend, not
+*This feature is only available when using the Forward+ renderer, not
 Mobile or Compatibility.*
 
 :abbr:`SSIL (Screen-Space Indirect Lighting)` provides indirect lighting for
@@ -533,7 +533,7 @@ Tweaking :abbr:`SSIL (Screen-Space Indirect Lighting)` is possible with several
 Signed Distance Field Global Illumination (SDFGI)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-*This feature is only available when using the Forward+ backend, not
+*This feature is only available when using the Forward+ renderer, not
 Mobile or Compatibility.*
 
 Signed distance field global illumination (SDFGI) is a form of real-time global
@@ -841,7 +841,7 @@ values result in a visually brighter scene.
 Auto Exposure
 ^^^^^^^^^^^^^
 
-*This feature is only available when using the Forward+ backend, not
+*This feature is only available when using the Forward+ renderer, not
 Mobile or Compatibility.*
 
 Even though, in most cases, lighting and texturing are heavily artist controlled,
diff --git a/tutorials/3d/global_illumination/reflection_probes.rst b/tutorials/3d/global_illumination/reflection_probes.rst
index 8f3eb1f8de7c..89be8460bba5 100644
--- a/tutorials/3d/global_illumination/reflection_probes.rst
+++ b/tutorials/3d/global_illumination/reflection_probes.rst
@@ -5,8 +5,8 @@ Reflection probes
 
 .. note::
 
-    Reflection probes are only supported in the Clustered Forward and Forward
-    Mobile rendering backends, not the Compatibility backend.
+    Reflection probes are only supported in the Forward+ and Mobile renderers,
+    not the Compatibility renderer.
 
 As stated in the :ref:`doc_standard_material_3d`, objects can show reflected and/or
 diffuse light. Reflection probes are used as a source of reflected *and* ambient
@@ -191,10 +191,10 @@ an omni light, a spot light, a :ref:`decal <doc_using_decals>` or a
 adjusting the **Rendering > Limits > Cluster Builder > Max Clustered Elements**
 advanced project setting.
 
-When using the Forward Mobile backend, only 8 reflection probes can be applied on each
+When using the Mobile renderer, only 8 reflection probes can be applied on each
 individual Mesh *resource*. If there are more reflection probes affecting a single mesh,
 not all of them will be rendered on the mesh.
 
-Similarly, when using the Compatibility backend, up to 2 reflection probes can be applied
-per mesh. If more than 2 reflection probes affect a single mesh, additional probes will
-not be rendered.
+Similarly, when using the Compatibility renderer, up to 2 reflection probes can
+be applied per mesh. If more than 2 reflection probes affect a single mesh,
+additional probes will not be rendered.
diff --git a/tutorials/3d/global_illumination/using_sdfgi.rst b/tutorials/3d/global_illumination/using_sdfgi.rst
index f2534373a034..fc446705fdd5 100644
--- a/tutorials/3d/global_illumination/using_sdfgi.rst
+++ b/tutorials/3d/global_illumination/using_sdfgi.rst
@@ -18,8 +18,8 @@ its performance requirements at the cost of quality.
 
 .. important::
 
-    SDFGI is only supported when using the Forward Plus rendering backend,
-    not the Forward Mobile or Compatibility backends.
+    SDFGI is only supported when using the Forward+ renderer, not the Mobile or
+    Compatibility renderers.
 
 .. seealso::
 
diff --git a/tutorials/3d/global_illumination/using_voxel_gi.rst b/tutorials/3d/global_illumination/using_voxel_gi.rst
index 7f7b6ce4ce2b..cb753aa54296 100644
--- a/tutorials/3d/global_illumination/using_voxel_gi.rst
+++ b/tutorials/3d/global_illumination/using_voxel_gi.rst
@@ -9,8 +9,8 @@ it's best used when targeting dedicated graphics cards.
 
 .. important::
 
-    VoxelGI is only supported when using the Forward Plus rendering backend,
-    not the Forward Mobile or Compatibility backends.
+    VoxelGI is only supported when using the Forward+ renderer, not the Mobile or
+    Compatibility renderers.
 
 .. seealso::
 
diff --git a/tutorials/3d/lights_and_shadows.rst b/tutorials/3d/lights_and_shadows.rst
index f2806896a0cc..aaf03caef247 100644
--- a/tutorials/3d/lights_and_shadows.rst
+++ b/tutorials/3d/lights_and_shadows.rst
@@ -65,10 +65,9 @@ an omni light, a spot light, a :ref:`decal <doc_using_decals>` or a
 adjusting the **Rendering > Limits > Cluster Builder > Max Clustered Elements**
 advanced project setting.
 
-When using the Forward Mobile renderer, there is a limitation of 8 OmniLights +
-8 SpotLights per mesh resource. There is also a limit of 256 OmniLights + 256
-SpotLights that can be rendered in the current camera view. These limits
-currently cannot be changed.
+When using the Mobile renderer, there is a limitation of 8 OmniLights + 8 SpotLights
+per mesh resource. There is also a limit of 256 OmniLights + 256 SpotLights that
+can be rendered in the current camera view. These limits currently cannot be changed.
 
 When using the Compatibility renderer, up to 8 OmniLights + 8 SpotLights can be
 rendered per mesh resource. This limit can be increased in the advanced Project
@@ -88,7 +87,7 @@ nodes can help reduce this issue while also improving performance. Splitting
 your meshes into smaller portions can also help, especially for level geometry
 (which also improves culling efficiency).
 
-If you need to render more lights than possible in a given rendering backend,
+If you need to render more lights than possible in a given renderer,
 consider using :ref:`baked lightmaps <doc_using_lightmap_gi>` with lights' bake
 mode set to **Static**. This allows lights to be fully baked, which also makes
 them much faster to render. You can also use emissive materials with any
diff --git a/tutorials/3d/occlusion_culling.rst b/tutorials/3d/occlusion_culling.rst
index d5e97098fb59..ad2c0f05028e 100644
--- a/tutorials/3d/occlusion_culling.rst
+++ b/tutorials/3d/occlusion_culling.rst
@@ -58,16 +58,16 @@ performance gains.
 
 .. note::
 
-    When using the Clustered Forward rendering backend, the engine already
+    When using the Forward+ renderer, the engine already
     performs a *depth prepass*. This consists in rendering a depth-only version
     of the scene before rendering the scene's actual materials. This is used to
     ensure each opaque pixel is only shaded once, reducing the cost of overdraw
     significantly.
 
-    The greatest performance benefits can be observed when using the Forward
-    Mobile rendering backend, as it does not feature a
-    depth prepass for performance reasons. As a result, occlusion culling will
-    actively decrease shading overdraw with that rendering backend.
+    The greatest performance benefits can be observed when using the Mobile
+    renderer, as it does not feature a depth prepass for performance reasons. As
+    a result, occlusion culling will actively decrease shading overdraw with 
+    that renderer.
 
     Nonetheless, even when using a depth prepass, there is still a noticeable
     benefit to occlusion culling in complex 3D scenes. However, in scenes with
diff --git a/tutorials/3d/using_decals.rst b/tutorials/3d/using_decals.rst
index dcb2f07ac474..49f7d9eb0d60 100644
--- a/tutorials/3d/using_decals.rst
+++ b/tutorials/3d/using_decals.rst
@@ -5,10 +5,10 @@ Using decals
 
 .. note::
 
-    Decals are only supported in the Clustered Forward and Forward Mobile
-    rendering backends, not the Compatibility backend.
+    Decals are only supported in the Forward+ and Mobile renderers, not the 
+    Compatibility renderer.
 
-    If using the Compatibility backend, consider using Sprite3D as an alternative
+    If using the Compatibility renderer, consider using Sprite3D as an alternative
     for projecting decals onto (mostly) flat surfaces.
 
 Decals are projected textures that apply on opaque or transparent surfaces in
@@ -266,6 +266,6 @@ an omni light, a spot light, a :ref:`decal <doc_using_decals>` or a
 adjusting the **Rendering > Limits > Cluster Builder > Max Clustered Elements**
 advanced project setting.
 
-When using the Forward Mobile backend, only 8 decals can be applied on each
+When using the Mobile renderer, only 8 decals can be applied on each
 individual Mesh *resource*. If there are more decals affecting a single mesh,
 not all of them will be rendered on the mesh.
diff --git a/tutorials/3d/variable_rate_shading.rst b/tutorials/3d/variable_rate_shading.rst
index 81b902c25cf4..19bcabe4f82e 100644
--- a/tutorials/3d/variable_rate_shading.rst
+++ b/tutorials/3d/variable_rate_shading.rst
@@ -83,11 +83,10 @@ Using variable rate shading in Godot
 
 .. note::
 
-    Both Forward Plus and Forward Mobile rendering methods support variable rate
+    Both Forward+ and Mobile renderers support variable rate
     shading. VRS can be used in both pancake (non-XR) and XR display modes.
 
-    The Compatibility rendering method does **not** support variable rate
-    shading.
+    The Compatibility renderer does **not** support variable rate shading.
 
 In the advanced Project Settings, the **Rendering > VRS** section offers settings
 to control variable rate shading on the root viewport:
diff --git a/tutorials/3d/volumetric_fog.rst b/tutorials/3d/volumetric_fog.rst
index e32acee83440..1f021e184e58 100644
--- a/tutorials/3d/volumetric_fog.rst
+++ b/tutorials/3d/volumetric_fog.rst
@@ -5,8 +5,8 @@ Volumetric fog and fog volumes
 
 .. note::
 
-    Volumetric fog is only supported in the Clustered Forward rendering backend,
-    not Forward Mobile or Compatibility.
+    Volumetric fog is only supported in the Forward+ renderer, not the Mobile or
+    Compatibility renderers.
 
 As described in :ref:`doc_environment_and_post_processing`, Godot supports
 various visual effects including two types of fog: traditional (non-volumetric)
@@ -270,7 +270,7 @@ Faking volumetric fog using quads
 In some cases, it may be better to use specially configured QuadMeshes as an
 alternative to volumetric fog:
 
-- Quads work with any rendering method, including Forward Mobile and Compatibility.
+- Quads work with any rendering method, including Mobile and Compatibility.
 - Quads do not require temporal reprojection to look smooth, which makes
   them suited to fast-moving dynamic effects such as lasers. They can also
   represent small details which volumetric fog cannot do efficiently.
diff --git a/tutorials/assets_pipeline/importing_images.rst b/tutorials/assets_pipeline/importing_images.rst
index 292e37d60da5..85d9b49fdc30 100644
--- a/tutorials/assets_pipeline/importing_images.rst
+++ b/tutorials/assets_pipeline/importing_images.rst
@@ -79,8 +79,8 @@ It is possible to choose other types of imported resources in the Import dock:
   custom shaders.
 - **CubemapArray:** Import the texture as a collection of 6-sided cubemaps,
   which can be sampled in custom shaders. This resource type can only be
-  displayed when using the Forward+ or Forward Mobile rendering methods, not
-  Compatibility.
+  displayed when using the Forward+ or Mobile renderers, not the Compatibility
+  renderer.
 - **Font Data (Monospace Image Font):** Import the image as a bitmap font where
   all characters have the same width. See :ref:`doc_gui_using_fonts`.
 - **Image:** Import the image as-is. This resource type cannot be displayed
@@ -261,10 +261,10 @@ Compress > High Quality
 .. note::
 
     High-quality VRAM texture compression is only supported in the Forward+ and
-    Forward Mobile rendering methods.
+    Mobile renderers.
 
-    When using the Compatibility rendering method, this option is always
-    considered disabled.
+    When using the Compatibility renderer, this option is always considered
+    disabled.
 
 If enabled, uses BPTC compression on desktop platforms and :abbr:`ASTC (Adaptive
 Scalable Texture Compression)` compression on mobile platforms. When using BPTC,
diff --git a/tutorials/editor/project_manager.rst b/tutorials/editor/project_manager.rst
index c454faf84f31..126522f11705 100644
--- a/tutorials/editor/project_manager.rst
+++ b/tutorials/editor/project_manager.rst
@@ -38,7 +38,7 @@ To create a new project:
    you can enable **Create Folder** option to automatically create a new sub-folder
    with the project name, following the directory naming convention set in the
    settings. An empty folder will show a green tick on the right.
-3. Select one of the rendering backends (this can also be changed later).
+3. Select one of the renderers (this can also be changed later).
 4. Click the **Create & Edit** button to create the project folder and open it in the editor.
 
 .. image:: img/editor_ui_intro_project_manager_04.webp
diff --git a/tutorials/migrating/upgrading_to_godot_4.rst b/tutorials/migrating/upgrading_to_godot_4.rst
index 57f7b99f7dcc..8e951596c09a 100644
--- a/tutorials/migrating/upgrading_to_godot_4.rst
+++ b/tutorials/migrating/upgrading_to_godot_4.rst
@@ -50,7 +50,7 @@ Godot 3.x for the following reasons:
   :ref:`exporting to the Web <doc_exporting_for_web>`, as binary size directly
   influences how fast the engine can initialize (regardless of download speed).
 - Godot 4 does not and will not have support for GLES2 rendering.
-  (There is still support for GLES3 rendering using the new OpenGL backend,
+  (There is still support for GLES3 rendering using the new Compatibility renderer,
   which means that devices without Vulkan support can still run Godot 4.)
 
   - If you are targeting **very** old hardware such as Intel Sandy Bridge (2nd
@@ -75,9 +75,9 @@ in future Godot releases:
   "overbright" modulate values have no visible effect. Since Godot 4.2, you can
   enable the project setting :ref:`HDR 2D<class_ProjectSettings_property_rendering/viewport/hdr_2d>`
   to perform 2D rendering in HDR. See also :ref:`doc_environment_and_post_processing_using_glow_in_2d`.
-- While rendering still happens in HDR in 3D when using the Forward Plus or
-  Forward Mobile backends, Viewports cannot return HDR data anymore. This is
-  planned to be restored at some point in the future.
+- While rendering still happens in HDR in 3D when using the Forward+ or Mobile
+  renderers, Viewports cannot return HDR data anymore. This is planned to be 
+  restored at some point in the future.
 - Mono was replaced by .NET 6. This means exporting C# projects to Android, iOS
   and HTML5 is no longer supported for now. Exporting C# projects to desktop
   platforms is still supported, and as of 4.2 there's experimental support for
diff --git a/tutorials/rendering/renderers.rst b/tutorials/rendering/renderers.rst
index 4b124d599f66..530671414839 100644
--- a/tutorials/rendering/renderers.rst
+++ b/tutorials/rendering/renderers.rst
@@ -14,14 +14,13 @@ Introduction
 
 Godot 4 includes three renderers:
 
-- **Forward+**, sometimes called **Clustered Forward**. The most advanced renderer,
-  suited for desktop platforms only. Used by default on desktop platforms. This
-  renderer uses **Vulkan**, **Direct3D 12**, or **Metal** as the rendering driver,
-  and it uses the **RenderingDevice** backend.
-- **Mobile**, sometimes called **Forward Mobile**. Fewer features, but renders
-  simple scenes faster. Suited for mobile and desktop platforms. Used by default
-  on mobile platforms. This renderer uses **Vulkan**, **Direct3D 12**, or **Metal**
-  as the rendering driver, and it uses the **RenderingDevice** backend.
+- **Forward+**. The most advanced renderer, suited for desktop platforms only.
+  Used by default on desktop platforms. This renderer uses **Vulkan**, **Direct3D 12**,
+  or **Metal** as the rendering driver, and it uses the **RenderingDevice** backend.
+- **Mobile**. Fewer features, but renders simple scenes faster. Suited for mobile
+  and desktop platforms. Used by default on mobile platforms. This renderer uses
+  **Vulkan**, **Direct3D 12**, or **Metal** as the rendering driver, and it uses
+  the **RenderingDevice** backend.
 - **Compatibility**, sometimes called **GL Compatibility**. The least advanced
   renderer, suited for low-end desktop and mobile platforms. Used by default on
   the web platform. This renderer uses **OpenGL** as the rendering driver.
diff --git a/tutorials/shaders/advanced_postprocessing.rst b/tutorials/shaders/advanced_postprocessing.rst
index 1f508141524d..12535ea98770 100644
--- a/tutorials/shaders/advanced_postprocessing.rst
+++ b/tutorials/shaders/advanced_postprocessing.rst
@@ -104,14 +104,15 @@ inverse of the projection matrix, which in Godot, is accessible with the variabl
 
 Firstly, take the screen space coordinates and transform them into normalized device
 coordinates (NDC). NDC run ``-1.0`` to ``1.0`` in ``x`` and ``y`` directions and
-from ``0.0`` to ``1.0`` in the ``z`` direction when using the Vulkan backend.
-Reconstruct the NDC using ``SCREEN_UV`` for the ``x`` and ``y`` axis, and
-the depth value for ``z``.
+from ``0.0`` to ``1.0`` in the ``z`` direction when using the Forward+ or Mobile
+renderers. Reconstruct the NDC using ``SCREEN_UV`` for the ``x`` and ``y`` axis,
+and the depth value for ``z``.
 
 .. note::
 
-    This tutorial assumes the use of the Vulkan renderer, which uses NDCs with a Z-range
-    of ``[0.0, 1.0]``. In contrast, OpenGL uses NDCs with a Z-range of ``[-1.0, 1.0]``.
+    This tutorial assumes the use of the Forward+ or Mobile renderers, which uses
+    Vulkan NDCs with a Z-range of ``[0.0, 1.0]``. In contrast, the Compatibility
+    renderer uses OpenGL NDCs with a Z-range of ``[-1.0, 1.0]``.
 
 .. code-block:: glsl
 
diff --git a/tutorials/shaders/shader_reference/spatial_shader.rst b/tutorials/shaders/shader_reference/spatial_shader.rst
index 69354c5afc3f..e062998ec5e5 100644
--- a/tutorials/shaders/shader_reference/spatial_shader.rst
+++ b/tutorials/shaders/shader_reference/spatial_shader.rst
@@ -116,7 +116,7 @@ Global built-ins are available everywhere, including custom functions.
 | in float **E**              | An ``E`` constant (``2.718281``). Euler's number and a base of the natural logarithm.    |
 +-----------------------------+------------------------------------------------------------------------------------------+
 | in bool **OUTPUT_IS_SRGB**  | ``true`` when output is in sRGB color space (this is ``true`` in the Compatibility       |
-|                             | renderer, ``false`` in Forward+ and Forward Mobile).                                     |
+|                             | renderer, ``false`` in Forward+ and Mobile).                                             |
 +-----------------------------+------------------------------------------------------------------------------------------+
 | in float **CLIP_SPACE_FAR** | Clip space far ``z`` value.                                                              |
 |                             | In the Forward+ or Mobile renderers, it's ``0.0``.                                       |
diff --git a/tutorials/troubleshooting.rst b/tutorials/troubleshooting.rst
index 7b935c46c642..a78a9e713a03 100644
--- a/tutorials/troubleshooting.rst
+++ b/tutorials/troubleshooting.rst
@@ -60,8 +60,8 @@ There are several workarounds for this:
 The editor or project takes a very long time to start
 -----------------------------------------------------
 
-When using one of the Vulkan-based renderers (Forward+ or Forward Mobile),
-the first startup is expected to be relatively long. This is because shaders
+When using one of the Vulkan-based renderers (Forward+ or Mobile), the first
+startup is expected to be relatively long. This is because shaders
 need to be compiled before they can be cached. Shaders also need to be cached
 again after updating Godot, after updating graphics drivers or after switching
 graphics cards.
@@ -220,7 +220,7 @@ This is a known issue on Linux with NVIDIA graphics when using the proprietary
 driver. There is no definitive fix yet, as suspend on Linux + NVIDIA is often
 buggy when OpenGL or Vulkan is involved. The Compatibility rendering method
 (which uses OpenGL) is generally less prone to suspend-related issues compared
-to the Forward+ and Forward Mobile rendering methods (which use Vulkan).
+to the Forward+ and Mobile renderers (which use Vulkan).
 
 The NVIDIA driver offers an *experimental*
 `option to preserve video memory after suspend <https://wiki.archlinux.org/title/NVIDIA/Tips_and_tricks#Preserve_video_memory_after_suspend>`__