diff --git a/pw_assert/docs.rst b/pw_assert/docs.rst
index 9a03d64..aa43ca5 100644
--- a/pw_assert/docs.rst
+++ b/pw_assert/docs.rst
@@ -12,7 +12,7 @@
 defensive programming that can lead to more reliable and less buggy code.
 
 The assert API facilitates flexible crash handling through Pigweed's facade
-mechanism. The API is desigend to enable features like:
+mechanism. The API is designed to enable features like:
 
 - Optional ancillary printf-style messages along assertions
 - Capturing actual values of binary operator assertions like ``a < b``
@@ -649,12 +649,12 @@
 
 How should objects be asserted against or compared?
 ---------------------------------------------------
-Unfortunatly, there is no native mechanism for this, and instead the way to
+Unfortunately, there is no native mechanism for this, and instead the way to
 assert object states or comparisons is with the normal ``PW_CHECK_*`` macros
 that operate on booleans, ints, and floats.
 
 This is due to the requirement of supporting C and also tokenization. It may be
-possible support rich object comparions by defining a convention for
+possible support rich object comparisons by defining a convention for
 stringifying objects; however, this hasn't been added yet. Additionally, such a
 mechanism would not work well with tokenization. In particular, it would
 require runtime stringifying arguments and rendering them with ``%s``, which
diff --git a/pw_boot_armv7m/docs.rst b/pw_boot_armv7m/docs.rst
index d00bec4..48bd3e4 100644
--- a/pw_boot_armv7m/docs.rst
+++ b/pw_boot_armv7m/docs.rst
@@ -51,7 +51,7 @@
 
  - ``int main()``: This is where applications reside.
  - ``void pw_boot_PreStaticMemoryInit()``: This function executes just before
-   static memory has been zerod and static data is intialized. This function
+   static memory has been zeroed and static data is intialized. This function
    should set up any early initialization that should be done before static
    memory is initialized, such as:
 
diff --git a/pw_fuzzer/docs.rst b/pw_fuzzer/docs.rst
index fb406e1..a221e2b 100644
--- a/pw_fuzzer/docs.rst
+++ b/pw_fuzzer/docs.rst
@@ -48,7 +48,7 @@
 
 When writing you fuzz target function, you may want to consider:
 
-- It is acceptable to return early if the input doesn't mean some constraints,
+- It is acceptable to return early if the input doesn't meet some constraints,
   e.g. it is too short.
 - If your fuzzer accepts data with a well-defined format, you can bootstrap
   coverage by crafting examples and adding them to a `corpus`_.
diff --git a/pw_kvs/docs.rst b/pw_kvs/docs.rst
index 7504566..29b3848 100644
--- a/pw_kvs/docs.rst
+++ b/pw_kvs/docs.rst
@@ -49,7 +49,7 @@
 entries for that key are not modified or removed from flash storage, until
 garbage collection reclaims the “stale” entries.
 
-`Garbage collection`_ is done by coping any currently valid KV entries in the
+`Garbage collection`_ is done by copying any currently valid KV entries in the
 sector to be garbage collected to a different sector and then erasing the
 sector.
 
diff --git a/pw_metric/docs.rst b/pw_metric/docs.rst
index 6bdcd5a..2b9d20e 100644
--- a/pw_metric/docs.rst
+++ b/pw_metric/docs.rst
@@ -150,7 +150,7 @@
   UART). In those cases, metrics provide a low-overhead approach to understand
   what is happening. During early boot, metrics can be incremented, then after
   boot dumping the metrics provides insights into what happened. While basic
-  counter variables can work in these contexts to, one still has to deal with
+  counter variables can work in these contexts too, one still has to deal with
   the offloading problem; which the library handles.
 
 ---------------------
@@ -308,7 +308,7 @@
       }
 
   You can also put a metric into a group with the macro. Metrics can belong to
-  strictly one group, otherwise a assertion will fail. Example:
+  strictly one group, otherwise an assertion will fail. Example:
 
   .. code::
 
@@ -653,7 +653,7 @@
     "/i2c1/gyro/resets": 24,
     "/i2c1/gyro/hangs": 1,
     "/spi1/thermocouple/reads": 242,
-    "/spi1/thermocouple/temp_celcius": 34.52,
+    "/spi1/thermocouple/temp_celsius": 34.52,
   }
 
 Note that there is no nesting of the groups; the nesting is implied from the
@@ -717,8 +717,8 @@
 
   Calls to is ``MetricService::Get`` are blocking and will send all metrics
   immediately, even though it is a server-streaming RPC. This will work fine if
-  the device doesn't have too many metics, or doesn't have concurrent RPCs like
-  logging, but could be a problem in some cases.
+  the device doesn't have too many metrics, or doesn't have concurrent RPCs
+  like logging, but could be a problem in some cases.
 
   We plan to offer an async version where the application is responsible for
   pumping the metrics into the streaming response. This gives flow control to
@@ -818,7 +818,7 @@
   metrics are enabled or disabled at compile time. This may rely on of C++20's
   support for zero-sized members to fully remove the cost.
 
-- **Async RCPC** - The current RPC service exports the metrics by streaming
+- **Async RPC** - The current RPC service exports the metrics by streaming
   them to the client in batches. However, the current solution streams all the
   metrics to completion; this may block the RPC thread. In the future we will
   have an async solution where the user is in control of flow priority.
diff --git a/pw_package/docs.rst b/pw_package/docs.rst
index b3055db..24037e5 100644
--- a/pw_package/docs.rst
+++ b/pw_package/docs.rst
@@ -32,7 +32,7 @@
   ``--force`` to remove the package before installing.
 
 ``pw package status <package-name>``
-  Indicates whether ``<packagxe-name>`` is installed.
+  Indicates whether ``<package-name>`` is installed.
 
 ``pw package remove <package-name>``
   Removes ``<package-name>``.
diff --git a/pw_persistent_ram/docs.rst b/pw_persistent_ram/docs.rst
index 71b9935..ef99710 100644
--- a/pw_persistent_ram/docs.rst
+++ b/pw_persistent_ram/docs.rst
@@ -75,8 +75,8 @@
 are initialized in RAM.
 
 The preferred way to clear Persistent RAM is to simply zero entire persistent
-RAM sections and/or memory regions. Pigweed's persistents containers have picked
-integrity checks which work with zerod memory, meaning they do not hold a value
+RAM sections and/or memory regions. Pigweed's persistent containers have picked
+integrity checks which work with zeroed memory, meaning they do not hold a value
 after zeroing. Alternatively containers can be individually cleared.
 
 The boot sequence itself is tightly coupled to the number of persistent sections
diff --git a/pw_preprocessor/docs.rst b/pw_preprocessor/docs.rst
index 3f5b13c..03d22bb 100644
--- a/pw_preprocessor/docs.rst
+++ b/pw_preprocessor/docs.rst
@@ -30,12 +30,12 @@
   .. code-block:: cpp
 
       #define ARG_PRINT(...)  PW_DELEGATE_BY_ARG_COUNT(_ARG_PRINT, __VA_ARGS__)
-      #define _ARG_PRINT_0(a)        LOG_INFO("nothing!")
-      #define _ARG_PRINT_1(a)        LOG_INFO("1 arg: %s", a)
-      #define _ARG_PRINT_2(a, b)     LOG_INFO("2 args: %s, %s", a, b)
-      #define _ARG_PRINT_3(a, b, c)  LOG_INFO("3 args: %s, %s, %s", a, b, c)
+      #define _ARG_PRINT0(a)        LOG_INFO("nothing!")
+      #define _ARG_PRINT1(a)        LOG_INFO("1 arg: %s", a)
+      #define _ARG_PRINT2(a, b)     LOG_INFO("2 args: %s, %s", a, b)
+      #define _ARG_PRINT3(a, b, c)  LOG_INFO("3 args: %s, %s, %s", a, b, c)
 
-  When used, ``ARG_PRINT`` expands to the ``_ARG_PRINT_#`` macro corresponding
+  When used, ``ARG_PRINT`` expands to the ``_ARG_PRINT#`` macro corresponding
   to the number of arguments.
 
   .. code-block:: cpp
diff --git a/pw_sys_io/docs.rst b/pw_sys_io/docs.rst
index 3a1a6c4..eaf60ba 100644
--- a/pw_sys_io/docs.rst
+++ b/pw_sys_io/docs.rst
@@ -30,7 +30,7 @@
 =====
 This module requires relatively minimal setup:
 
-  1. Chose a ``pw_sys_io`` backend, or write one yourself.
+  1. Choose a ``pw_sys_io`` backend, or write one yourself.
   2. If using GN build, Specify the ``pw_sys_io_BACKEND`` GN build arg to point
      the library that provides a ``pw_sys_io`` backend.
 
diff --git a/pw_trace/docs.rst b/pw_trace/docs.rst
index 60aa359..30cf831 100644
--- a/pw_trace/docs.rst
+++ b/pw_trace/docs.rst
@@ -280,7 +280,7 @@
 ----------------------
 Python Trace Generator
 ----------------------
-The Python tool is still in early developments, but currently it supports
+The Python tool is still in early development, but currently it supports
 generating a list of json lines from a list of trace events.
 
 To view the trace, these lines can be saved to a file and loaded into
diff --git a/pw_trace_tokenized/docs.rst b/pw_trace_tokenized/docs.rst
index c1c27ac..82034dc 100644
--- a/pw_trace_tokenized/docs.rst
+++ b/pw_trace_tokenized/docs.rst
@@ -16,7 +16,7 @@
 This module is currently in development, and is therefore still undergoing
 significant changes.
 
-Future work will add:
+Future work will:
 
 1. Add a more complete API for how to retrieve data from ring_buffer.
 2. Add a Python library to decode the trace data.
@@ -60,7 +60,7 @@
 ---------
 Macro API
 ---------
-All code should use the trace API facade directly, this backend fully
+All code should use the trace API facade directly. This backend fully
 implements all features of the tracing facade.
 
 
@@ -139,7 +139,7 @@
 -----------
 Time source
 -----------
-Tracing rquires the platform to provide the time source for tracing, this can
+Tracing requires the platform to provide the time source for tracing, this can
 be done in one of a few ways.
 
 1. Create a file with the default time functions, and provide as build variable
@@ -159,7 +159,7 @@
 ------
 The optional trace buffer adds a ring buffer which contains the encoded trace
 data. This is still a work in progress, in particular better methods for
-retireving the data still needs to be added. Currently there is an accessor for
+retrieving the data still need to be added. Currently there is an accessor for
 the underlying ring buffer object, but this is a short term solution.
 
 .. cpp:function:: void ClearBuffer()