diff --git a/Documentation/Doxygen/Iterators.dox b/Documentation/Doxygen/Iterators.dox
index 58584edb32a..abcf9f294f6 100644
--- a/Documentation/Doxygen/Iterators.dox
+++ b/Documentation/Doxygen/Iterators.dox
@@ -140,7 +140,7 @@
   Another group of iterators support a moving neighborhood. Here the
   neighborhood can "iterate" over an image and a calculation can iterate
   over the neighborhood.  This allows N-dimensional implementations of
-  convolution and finite differences to be implemented succintly.
+  convolution and finite differences to be implemented succinctly.
   This class of iterators is described in detail on the page
   \ref NeighborhoodIteratorsPage.
 
diff --git a/Documentation/Doxygen/Modules.dox b/Documentation/Doxygen/Modules.dox
index b5ed15b5366..3d43898cf7f 100644
--- a/Documentation/Doxygen/Modules.dox
+++ b/Documentation/Doxygen/Modules.dox
@@ -609,7 +609,7 @@
   \defgroup Deprecated Deprecated Classes
 
   Classes that are scheduled to be removed from the toolkit. Their
-  funcionality is now provided by other classes or changes in the toolkit have
+  functionality is now provided by other classes or changes in the toolkit have
   made them useless. Please report to their documentation and look in to their
   "Deprecated" section. This section should indicate what to do to replace
   this class in any affected code.
diff --git a/Documentation/Doxygen/Registration.dox b/Documentation/Doxygen/Registration.dox
index cf5a8cdd6d1..0a7d1b735c7 100644
--- a/Documentation/Doxygen/Registration.dox
+++ b/Documentation/Doxygen/Registration.dox
@@ -58,7 +58,7 @@ This is a rapid description of the transforms implemented in the toolkit
 
 \li \b Rigid3D: This transform is specific for 3D, it supports only rotations and translations. Rotations are represented using \e Quaternions.
 
-\li \b Rigid3DPerspective: A composition of a \e Rigid3D transform followed by a perpective projection. This transformation is intended to be used in applications like X-Rays projections.
+\li \b Rigid3DPerspective: A composition of a \e Rigid3D transform followed by a perspective projection. This transformation is intended to be used in applications like X-Rays projections.
 
 \li \b Translation: A N-Dimensional translation internally represented as a vector.
 
@@ -95,7 +95,7 @@ The following optimization methods are available:
 
 \li <b> Amoeba </b>: Nelder Meade Downhill Simplex.
 
-\li <b> One Plus One Evolutionary </b>: Stategy that simulates the biological evolution of a set of samples in the search space.
+\li <b> One Plus One Evolutionary </b>: Strategy that simulates the biological evolution of a set of samples in the search space.
 
 
 
diff --git a/Documentation/docs/contributing/document_itk.md b/Documentation/docs/contributing/document_itk.md
index 8f88ae4d611..ea01db4a431 100644
--- a/Documentation/docs/contributing/document_itk.md
+++ b/Documentation/docs/contributing/document_itk.md
@@ -142,5 +142,5 @@ and the second one being the title of the example in the
 #### Maintaining the documentation
 
 The documentation is built nightly on the latest ITK commit, and deployed to GitHub pages
-at https://insightsoftwareconsortium.github.io/ITKDoxygen/, whose code is maintaned at
+at https://insightsoftwareconsortium.github.io/ITKDoxygen/, whose code is maintained at
 https://github.com/InsightSoftwareConsortium/ITKDoxygen.
diff --git a/Documentation/docs/learn/dicom.md b/Documentation/docs/learn/dicom.md
index adbd233e805..5424af7b5ae 100644
--- a/Documentation/docs/learn/dicom.md
+++ b/Documentation/docs/learn/dicom.md
@@ -6,7 +6,7 @@ A question that is often asked is: I am trying to read/write a DICOM image,
 but the pixel data has changed (the scalar range has changed from input file).
 
 This surely comes from the fact that you did not used the proper
-pixel type to instanciate your reader. You have to consider:
+pixel type to instantiate your reader. You have to consider:
 
 - `Bits Allocated`
 - `Bits Stored`
@@ -114,7 +114,7 @@ is however allowed that both files uses different transfer syntax uid
 (implicit/explicit, little/big endian). When a DICOM file is sent to a
 PACS, it is up to the implementor to decide what to do in case of
 duplicate `SOP Instance UID`. In most case you should expect that the
-image is not resent, as standard garantee this is already the same
+image is not resent, as standard guarantee this is already the same
 object.
 
 > ⚠️ **Warning**
diff --git a/Documentation/docs/learn/faq.md b/Documentation/docs/learn/faq.md
index 67b5d46358e..94a05808097 100644
--- a/Documentation/docs/learn/faq.md
+++ b/Documentation/docs/learn/faq.md
@@ -66,7 +66,7 @@ possible to read/write 3D datasets as collections of 2D slices each one
 in an independent BMP, PNG or JPEG file by using the
 [`ImageSeriesReader`](https://itk.org/Doxygen/html/classitk_1_1ImageSeriesReader.html) and [`itk::ImageSeriesWriter`](https://itk.org/Doxygen/html/classitk_1_1ImageSeriesWriter.html).
 
-‡ It is higly recommended not using this format. RAW is not a format, it
+‡ It is highly recommended not using this format. RAW is not a format, it
 is insufficient, inconsistent and simply dangerous. A RAW file without a
 header is useless, and once you add a header, it is not RAW anymore.
 
@@ -158,7 +158,7 @@ GDCM is an open source package developed by the Creatis team at
 INSA-Lyon. It is distributed under a license similar to ITK: http://gdcm.sourceforge.net/Copyright.html.
 
 GCDM uses CMake in order to configure its build process, so you will
-find a familiar setup. Once you download, configure and buid GDCM, you
+find a familiar setup. Once you download, configure and build GDCM, you
 can reconfigure ITK by running CMake in your ITK build, going into the
 advanced options and enabling `USE_GDCM`.
 
@@ -461,7 +461,7 @@ the `Pixel Data` (`0x7fe0,0x0010`), thus it imply that the unused bits are
 **zeros**. In ITK, there is no such thing as 12-bit pixel type, thus
 when instanciating your reader you declare a 16-bit pixel type. This
 buffer is then passed back to GDCM which sees an array of 16bits values
-and then simply used the simpliest way to store this buffer back on
+and then simply used the simplest way to store this buffer back on
 disk: `Bits Stored = 16` and `High Bit = 15`. In case you have not made any
 change to your pixel buffer, implicitly the first 4 bits will be zero
 again. The only difference being that they are not as clearly declared
diff --git a/Documentation/docs/learn/fda_sw_development_guidelines.md b/Documentation/docs/learn/fda_sw_development_guidelines.md
index ad7fa2c7169..226e14e3fb3 100644
--- a/Documentation/docs/learn/fda_sw_development_guidelines.md
+++ b/Documentation/docs/learn/fda_sw_development_guidelines.md
@@ -37,11 +37,11 @@ development of your application. That will included things like:
 
 It is worth to point out that the software development process using in
 ITK and VTK are already following many of the FDA Guidelines for
-software developement. In particular
+software development. In particular
 
 - Continuous Testing via Dashboard ([CTest](https://cmake.org/cmake/help/latest/manual/ctest.1.html))
 - Version control ([git](https://git-scm.com/))
-- Configuration standarization ([CMake](https://cmake.org/))
+- Configuration standardization ([CMake](https://cmake.org/))
 - Bug tracking ([GitHub](https://github.com/features/issues)/[GitLab issues](https://docs.gitlab.com/ee/user/project/issues/))
 
 ## General guidelines
@@ -57,5 +57,5 @@ medical devices you must look at the following documents:
 - [Guidance for the Submission of Premarket Notifications For Radionuclide Dose Calibrators - Guidance for Industry](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/guidance-submission-premarket-notifications-radionuclide-dose-calibrators-guidance-industry)
 - [Content of Premarket Submissions for Device Software Functions](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-premarket-submissions-device-software-functions)
 
-These and other relevant documents can be found at the [FDA Guidance Doument search](https://www.fda.gov/regulatory-information/search-fda-guidance-documents)
+These and other relevant documents can be found at the [FDA Guidance Document search](https://www.fda.gov/regulatory-information/search-fda-guidance-documents)
 and the [Medical Devices and Radiation-Emitting Products Guidance Documents](https://www.fda.gov/medical-devices/device-advice-comprehensive-regulatory-assistance/guidance-documents-medical-devices-and-radiation-emitting-products) sites.
diff --git a/Documentation/docs/migration_guides/itk_5_migration_guide.md b/Documentation/docs/migration_guides/itk_5_migration_guide.md
index 884c93bb3e9..aceb8e8d8b9 100644
--- a/Documentation/docs/migration_guides/itk_5_migration_guide.md
+++ b/Documentation/docs/migration_guides/itk_5_migration_guide.md
@@ -312,7 +312,7 @@ and intuitive.
 SpatialObjects now only have two spaces and two transforms directly associated with them:
 * ObjectSpace is the space that is "local" to each object.   It is the physical space in which its data/parameters are defined.  For
 example, for an ImageSpatialObject it is the "PhysicalSpace" (see Image Class definition) of the Image.   For an Line/Tube/DTI and other
-point-based SpatialObjects, it is the inherent space in which the Point coordinates are specififed.   Typically, when a SpatialObject is
+point-based SpatialObjects, it is the inherent space in which the Point coordinates are specified.   Typically, when a SpatialObject is
 extracted from an Image, the parameters/coordinates of the SpatialObject are the space as the physical space of the source Image.   Any
 children of a SpatialObject are defined within the ObjectSpace of that parent SpatialObject.
 
diff --git a/Documentation/docs/migration_guides/itk_6_migration_guide.md b/Documentation/docs/migration_guides/itk_6_migration_guide.md
index f65992b7560..76176926621 100644
--- a/Documentation/docs/migration_guides/itk_6_migration_guide.md
+++ b/Documentation/docs/migration_guides/itk_6_migration_guide.md
@@ -108,7 +108,7 @@ ITK versions, `PointSet::Clone()` did not copy any data. (It previously just
 created a default-constructed PointSet object, like `PointSet::CreateAnother()`
 does.)
 
-For the sake of code readibility, a new `CoordinateType` alias is added for
+For the sake of code readability, a new `CoordinateType` alias is added for
 each nested `CoordRepType` alias. The old `CoordRepType` aliases will still be
 available with ITK 6.0, but it is recommended to use `CoordinateType` instead.
 The `CoordRepType` aliases will be removed when `ITK_FUTURE_LEGACY_REMOVE` is
diff --git a/Documentation/docs/scientific_ecosystem/itk_ecosystem.md b/Documentation/docs/scientific_ecosystem/itk_ecosystem.md
index 1551393a7d4..6834f57bec2 100644
--- a/Documentation/docs/scientific_ecosystem/itk_ecosystem.md
+++ b/Documentation/docs/scientific_ecosystem/itk_ecosystem.md
@@ -31,7 +31,7 @@ or sets of pipelines were:
 - [Praxix](https://code.google.com/archive/p/praxix/) was a collection
   of command line programs for image processing using ITK.
 - [ITK One Shot](https://github.com/daviddoria/ITK_OneShot) was a
-  collecion of short programs to perform specific operations on images.
+  collection of short programs to perform specific operations on images.
 - [ITKApps](https://github.com/InsightSoftwareConsortium/ITKApps) were
   a variety of applications written with ITK, ranging from simple uses
   of the toolkit to complex and GUI-based applications.