diff --git a/doc/programming/extension.rst b/doc/programming/extension.rst
index 8e777718..1963b213 100644
--- a/doc/programming/extension.rst
+++ b/doc/programming/extension.rst
@@ -312,7 +312,7 @@ gradient descent iterations is set using :ref:`sdf_iterations<option-sdf_iterati
 
 While *exact* SDFs---encoding the precise signed distance to the surface---are preferred, collisions are possible with
 any function whose value vanishes at the surface and grows monotonically away from it, with a negative sign in the
-interior. For such functions, it is still possible to find collisons, albeit with a possibly
+interior. For such functions, it is still possible to find collisions, albeit with a possibly
 increased number of starting points.
 
 The ``sdf_distance`` method is called by the compiler to produce a visual mesh for rendering using the marching cubes
@@ -331,7 +331,7 @@ For the sdf plugin, the following methods need to be specified
   required because mesh creation occurs during model compilation before the plugin object has been instantiated.
 
 ``sdf_gradient``:
-  Computes the gradient in local coodinates of the SDF at the query point.
+  Computes the gradient in local coordinates of the SDF at the query point.
 
 ``sdf_aabb``:
   Computes the axis-aligned bounding box in local coordinates. This volume is voxelized uniformly before the call to
@@ -392,7 +392,7 @@ Resource providers work via callbacks:
   resource name.  For example, the resource name ``http://www.example.com/myasset.obj`` would have
   ``http://www.example.com/`` as its directory.
 - :ref:`mjfResourceModified<mjfResourceModified>`: This callback is optional and is used to check if an existing
-  opened resource has been modifed from its orginal source.
+  opened resource has been modified from its original source.
 
 .. _exProviderUsage:
 
diff --git a/doc/programming/index.rst b/doc/programming/index.rst
index f6e4cb3e..6486ab61 100644
--- a/doc/programming/index.rst
+++ b/doc/programming/index.rst
@@ -143,7 +143,7 @@ links below, to make this documentation self-contained.
 
 `mujoco.h <https://github.com/google-deepmind/mujoco/blob/main/include/mujoco/mujoco.h>`__
    This is the main header file and must be included in all programs using MuJoCo. It defines all API functions and
-   global variables, and includes the all other header files except mjxmacro.h.
+   global variables, and includes all other header files except mjxmacro.h.
 `mjmodel.h <https://github.com/google-deepmind/mujoco/blob/main/include/mujoco/mjmodel.h>`__
    Defines the C structure :ref:`mjModel` which is the runtime representation of the
    model being simulated. It also defines a number of primitive types and other structures needed to define mjModel.
diff --git a/doc/programming/modeledit.rst b/doc/programming/modeledit.rst
index 8968d4cc..d7752964 100644
--- a/doc/programming/modeledit.rst
+++ b/doc/programming/modeledit.rst
@@ -18,7 +18,7 @@ Overview
 ~~~~~~~~
 
 The new API augments the traditional workflow of creating and editing models using XML files, breaking up the *parse* and
-*compile* steps. As summarized in the the :ref:`Overview chapter<Instance>`, the traditional workflow is:
+*compile* steps. As summarized in the :ref:`Overview chapter<Instance>`, the traditional workflow is:
 
  1. Create an XML model description file (MJCF or URDF) and associated assets. |br|
  2. Call :ref:`mj_loadXML`, obtain an :ref:`mjModel` instance.
@@ -29,7 +29,7 @@ The new workflow is:
     :ref:`mjSpec`.
  2. Edit the mutable :ref:`mjSpec` datastructure adding, changing and removing elements.
  3. Compile the :ref:`mjSpec` at any point, obtaining an updated :ref:`mjModel` instance. After compilation, the
-    :ref:`mjSpec` remains editable, so steps 2 and 3 are interchangable.
+    :ref:`mjSpec` remains editable, so steps 2 and 3 are interchangeable.
 
 
 .. _meUsage:
diff --git a/doc/programming/samples.rst b/doc/programming/samples.rst
index 40cbd434..019cc899 100644
--- a/doc/programming/samples.rst
+++ b/doc/programming/samples.rst
@@ -61,8 +61,8 @@ Where the command line arguments are
 - The ``ctrlnoise`` argument prevents models from settling into a static state where, due to warmstarts, one can
   measure artificially faster simulation.
 - When ``npoolthread > 1`` is specified, an engine-internal :ref:`mjThreadPool` is created with the specified number of
-  threads, to speed up simulation of large scenes. Note that while it is possible to to use both ``nthread`` and
-  ``npoolthread``, the scenarios for which one would want these different type of multithreading are usually mutually
+  threads, to speed up simulation of large scenes. Note that while it is possible to use both ``nthread`` and
+  ``npoolthread``, the scenarios for which one would want these different types of multithreading are usually mutually
   exclusive.
 - For more repeatable performance statistics, run the tool with the ``performance``
   `governor <https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt>`__ on Linux, or the
@@ -203,7 +203,7 @@ data file into a playable movie file:
    ffmpeg -f rawvideo -pixel_format rgb24 -video_size 2560x1440
           -framerate 60 -i rgb.out -vf "vflip,format=yuv420p" video.mp4
 
-Note that the offscreen rendering resolution of the model and ffmpeg's video_size must be the identical.
+Note that the offscreen rendering resolution of the model and ffmpeg's video_size must be identical.
 
 This sample can be compiled in three ways which differ in how the OpenGL context is created: using GLFW with an
 invisible window, using OSMesa, or using EGL. The latter two options are only available on Linux and are envoked by
diff --git a/doc/programming/visualization.rst b/doc/programming/visualization.rst
index ce60ba40..e8caa12c 100644
--- a/doc/programming/visualization.rst
+++ b/doc/programming/visualization.rst
@@ -151,7 +151,7 @@ The low-level mjvGLCamera is what determines the actual rendering. There are two
 for each eye. Each has position, forward and up directions. Forward corresponds to the negative Z axis of the camera
 frame, while up corresponds to the positive Y axis. There is also a frustum in the sense of OpenGL, except we store the
 average of the left and right frustum edges and then during rendering compute the actual edges from the viewport aspect
-ratio assuming 1:1 pixel aspect ratio. The distance between the two camera positions corresponds to the inter-pupilary
+ratio assuming 1:1 pixel aspect ratio. The distance between the two camera positions corresponds to the inter-pupillary
 distance (ipd). When the low-level camera parameters are computed automatically from an abstract camera, the ipd as well
 as vertical field of view (fovy) are taken from ``mjModel.vis.global.ipd``/``fovy`` for free and tracking cameras, and
 from the camera-specific ``mjModel.cam_ipd/fovy`` for cameras defined in the model. When stereoscopic mode is not