diff --git a/framework/doc/content/automatic_differentiation/index.md b/framework/doc/content/automatic_differentiation/index.md
index f61b55804c47..c81e980f52a7 100644
--- a/framework/doc/content/automatic_differentiation/index.md
+++ b/framework/doc/content/automatic_differentiation/index.md
@@ -205,7 +205,7 @@ the $\phi_i's$ are shape functions associated with the dofs. For a
 Lagrange basis, shape functions and dofs are tied to mesh nodes. To
 illustrate initiation of the AD process, we will consider construction of
 a local finite element solution on a `QUAD4` element, that is to say a
-quadrilaterial with a number of nodes equal to the number of vertices. This
+quadrilateral with a number of nodes equal to the number of vertices. This
 element type when combined with a Lagrange basis has four dofs which
 contribute to the local solution, one for each element node. In MOOSE we
 assign these local degree of freedom solution values (the local $u_i's$) to a
diff --git a/framework/doc/content/automatic_differentiation/templated_objects.md b/framework/doc/content/automatic_differentiation/templated_objects.md
index 1dbc2be1520b..a0f07b461481 100644
--- a/framework/doc/content/automatic_differentiation/templated_objects.md
+++ b/framework/doc/content/automatic_differentiation/templated_objects.md
@@ -53,7 +53,7 @@ The corresponding source file is
 
 !listing framework/src/kernels/BodyForce.C
 
-One important observation in this case is that this class (`BodyForcdeTempl`) derives
+One important observation in this case is that this class (`BodyForceTempl`) derives
 from a templated base class (`GenericKernel<is_ad`). This is slightly more complicated
 than the material example above. Members of the base class are not available in this
 derived class without including them with the `using` declaration in the header file
diff --git a/framework/doc/content/source/auxkernels/ConstantBoundsAux.md b/framework/doc/content/source/auxkernels/ConstantBoundsAux.md
index e8e974e5374c..3721339f7029 100644
--- a/framework/doc/content/source/auxkernels/ConstantBoundsAux.md
+++ b/framework/doc/content/source/auxkernels/ConstantBoundsAux.md
@@ -27,7 +27,7 @@ required to solve a constrained PDE defined by
 [this input file](/upper-and-lower-bound.i) with the various constraint
 algorithms is summarized below:
 
-- `viewntonrsls` and `ConstantBoundsAux`:                      22
+- `vinewtonrsls` and `ConstantBoundsAux`:                      22
 - `vinewtonssls` and `ConstantBoundsAux`:                      53
 - `UpperBoundNodalKernel` and `LowerBoundNodalKernel`: 25
 
diff --git a/framework/doc/content/source/auxkernels/HardwareIDAux.md b/framework/doc/content/source/auxkernels/HardwareIDAux.md
index 025dc4909bb0..9f96b22ec305 100644
--- a/framework/doc/content/source/auxkernels/HardwareIDAux.md
+++ b/framework/doc/content/source/auxkernels/HardwareIDAux.md
@@ -8,7 +8,7 @@ One of the main purposes of this object is to aid in the diagnostic of mesh part
 
 This is particularly interesting in the case of the [PetscExternalPartitioner](PetscExternalPartitioner.md) which has the capability to do "hierarchical" partitioning.  Hierarchical partitioning makes it possible to partition over compute-nodes first... then within compute nodes, in order to better respect the physical topology of the compute cluster.
 
-One important aspect of that is that how you launch your parallel job can matter quite a bit to partitioning.  In-general, it's better for partitioners if all of the ranks of your job are contiguously assigned to each compute node.  Here are four different ways, and the outcome using `HardwareIDAux`, to launch a job using a 100x100 generated mesh on 16 processes and 4 ndoes with two different partitioner...
+One important aspect of that is that how you launch your parallel job can matter quite a bit to partitioning.  In-general, it's better for partitioners if all of the ranks of your job are contiguously assigned to each compute node.  Here are four different ways, and the outcome using `HardwareIDAux`, to launch a job using a 100x100 generated mesh on 16 processes and 4 nodes with two different partitioner...
 
 Top left (METIS):
 
diff --git a/framework/doc/content/source/constraints/PeriodicSegmentalConstraint.md b/framework/doc/content/source/constraints/PeriodicSegmentalConstraint.md
index 58179b473d75..e2d285a9405b 100644
--- a/framework/doc/content/source/constraints/PeriodicSegmentalConstraint.md
+++ b/framework/doc/content/source/constraints/PeriodicSegmentalConstraint.md
@@ -103,7 +103,7 @@ directly opposite along the unit normal direction.
 As mentioned above, the $\lambda$ discretization needs to be continuous along patches
 of element faces (`LAGRANGE`, not `MONOMIAL`) in order to be stable, but must be discontinuous along
 corners of the mesh where the outward unit normal $\hat{n}$ is discontinuous since it is
-a flux variable (see the thrid condition [strong-form]). An easy way to do this is to make a
+a flux variable (see the third condition [strong-form]). An easy way to do this is to make a
 separate `LAGRANGE` variable for each 'face' of the model with different $\hat{n}$, which
 usually corresponds with different named side-sets or boundaries used for creating
 lower-dimensional mesh surfaces. This approach is demonstrated in many of the test input files.
diff --git a/framework/doc/content/source/dirackernels/ReporterPointSource.md b/framework/doc/content/source/dirackernels/ReporterPointSource.md
index 9edd2a86fbe5..023d98457e01 100644
--- a/framework/doc/content/source/dirackernels/ReporterPointSource.md
+++ b/framework/doc/content/source/dirackernels/ReporterPointSource.md
@@ -3,7 +3,7 @@
 A `ReporterPointSource` reads in multiple point sources from a `Reporter`.  The point source values and coordinates are updated as the `Reporter` values are changed.  
 
 An example of a `ReporterPointSource` using a [ConstantReporter](/ConstantReporter.md)
-and a `VectorPostrocessor` of type [CSVReader](/CSVReader.md) is given by:
+and a `VectorPostprocessor` of type [CSVReader](/CSVReader.md) is given by:
 
 !listing test/tests/dirackernels/reporter_point_source/2d_vpp.i block=reporter_point_source
 
@@ -12,7 +12,7 @@ The two ConstantReporters are given as:
 
 !listing test/tests/dirackernels/reporter_point_source/2d_vpp.i block=Reporters
 
-The `CSVReader` VectorPostrocessor is given by:
+The `CSVReader` VectorPostprocessor is given by:
 
 !listing test/tests/dirackernels/reporter_point_source/2d_vpp.i block=VectorPostprocessors
 
@@ -20,7 +20,7 @@ reading from the following csv file:
 
 !listing test/tests/dirackernels/reporter_point_source/point_value_file.csv
 
-The `Reporter` and `VectorPostrocessor` for the above example produce the same `ReporterPointSource` (e.g. same magnitude and location).   
+The `Reporter` and `VectorPostprocessor` for the above example produce the same `ReporterPointSource` (e.g. same magnitude and location).   
 
 The next example applies a `ReporterPointSource` in a transient simulation given by:
 
diff --git a/framework/doc/content/source/fvbcs/FVDirichletBC.md b/framework/doc/content/source/fvbcs/FVDirichletBC.md
index 8c3783b8cdf3..bdd5fdea6ad9 100644
--- a/framework/doc/content/source/fvbcs/FVDirichletBC.md
+++ b/framework/doc/content/source/fvbcs/FVDirichletBC.md
@@ -8,7 +8,7 @@ Dirichlet boundary conditions impose the boundary condition $u=g$, where $g$ is
 flux.
 
 Note that an upwinding scheme that may be used by flux kernels will affect how the Dirichlet value is applied to the interface. Upwinding schemes can result in the boundary solution being different than the specified Dirichlet value. In order to
-obtain the desired boundary value, it is necessary to use a FVNeummannBC to specify
+obtain the desired boundary value, it is necessary to use a FVNeumannBC to specify
 the flux.
 
 !syntax parameters /FVBCs/FVDirichletBC
diff --git a/framework/doc/content/source/interfaces/SetupInterface.md b/framework/doc/content/source/interfaces/SetupInterface.md
index b30fb0ccf1ab..d7f9e1758394 100644
--- a/framework/doc/content/source/interfaces/SetupInterface.md
+++ b/framework/doc/content/source/interfaces/SetupInterface.md
@@ -26,7 +26,7 @@ ALWAYS | Union of all the above flags.
 The "execute_on" parameter can be set to a single flag or multiple flags. For example, it may be
 desirable to only execute an object initially because the state of the auxiliary computation does not
 vary. In the input file snippet below, the [ElementLengthAux](/ElementLengthAux.md) computation only
-needs to be computed initially, thus the "exeucte_on" parameter is set as such.
+needs to be computed initially, thus the "execute_on" parameter is set as such.
 
 !listing test/tests/auxkernels/element_length/element_length.i block=AuxKernels
 
diff --git a/framework/doc/content/source/kernels/AnisotropicDiffusion.md b/framework/doc/content/source/kernels/AnisotropicDiffusion.md
index 90e83b10feaf..fbe78597646c 100644
--- a/framework/doc/content/source/kernels/AnisotropicDiffusion.md
+++ b/framework/doc/content/source/kernels/AnisotropicDiffusion.md
@@ -31,7 +31,7 @@ For a constant diffusion coefficient, the Jacobian is given by
 
 The `AnisotropicDiffusion` kernel may be used in a variety of physical models, including steady-state
 and time-dependent diffusion, advection-diffusion-reaction, etc. A kernel block demonstrating the
-`AnistropicDiffusion` syntax in a steady-state anisotropic diffusion problem can be found below:
+`AnisotropicDiffusion` syntax in a steady-state anisotropic diffusion problem can be found below:
 
 !listing test/tests/kernels/anisotropic_diffusion/aniso_diffusion.i block=Kernels
 
diff --git a/framework/doc/content/source/meshgenerators/MeshDiagnosticsGenerator.md b/framework/doc/content/source/meshgenerators/MeshDiagnosticsGenerator.md
index 34f088247048..fd070fa4a86e 100644
--- a/framework/doc/content/source/meshgenerators/MeshDiagnosticsGenerator.md
+++ b/framework/doc/content/source/meshgenerators/MeshDiagnosticsGenerator.md
@@ -104,7 +104,7 @@ The coarse element, if it were refined with MOOSE h-adaptivity, would be refined
 originally present in the mesh.
 
 This check will only detect mesh refinement for triangle and quadrilateral 2D elements and, tetrahedral and hexahedral 3D
-elements. For tetrahedrals, because the refinement pattern depends on the selection of a diagonal inside the coarse element,
+elements. For tetrahedra, because the refinement pattern depends on the selection of a diagonal inside the coarse element,
 the check only considers the `tip` fine elements on the four vertex of the coarse element.
 
 !alert note
diff --git a/framework/doc/content/source/postprocessors/AreaPostprocessor.md b/framework/doc/content/source/postprocessors/AreaPostprocessor.md
index fb6e41219ed5..14ac2de1553b 100644
--- a/framework/doc/content/source/postprocessors/AreaPostprocessor.md
+++ b/framework/doc/content/source/postprocessors/AreaPostprocessor.md
@@ -1,6 +1,6 @@
 # AreaPostprocessor
 
-The AreaPostprocesor is a SidePostprocessor that computes the area or dimension - 1 "volume" of a given side of the mesh. This
+The AreaPostprocessor is a SidePostprocessor that computes the area or dimension - 1 "volume" of a given side of the mesh. This
 postprocessor may be applied to one or more boundaries simultaneously, the latter case produces a total area is output.
 
 # Description and Syntax
diff --git a/framework/doc/content/source/variables/MooseVariableFV.md b/framework/doc/content/source/variables/MooseVariableFV.md
index 8ac84cac3852..1d1abbe38822 100644
--- a/framework/doc/content/source/variables/MooseVariableFV.md
+++ b/framework/doc/content/source/variables/MooseVariableFV.md
@@ -63,7 +63,7 @@ For background on the functor system see [Functors/index.md].
   `FaceArg` `limiter_type`. On external faces this will generally return a two
   term expansion using the cell center value and gradient unless
   `two_term_boundary_expansion` has been set to `false`. On Dirichlet faces this
-  will return the Diriclet value
+  will return the Dirichlet value
 - `ElemQpArg`: this forwards to `ElemPointArg` where the `point` is simply the
   quadrature point location
 - `ElemSideQpArg`: same as `ElemQpArg`
diff --git a/framework/doc/content/syntax/Adaptivity/index.md b/framework/doc/content/syntax/Adaptivity/index.md
index 35632831d28e..92c89c590b8f 100644
--- a/framework/doc/content/syntax/Adaptivity/index.md
+++ b/framework/doc/content/syntax/Adaptivity/index.md
@@ -24,8 +24,8 @@ higher than their parents.
 ## P-Refinement
 
 P-refinement level mismatches are not supported for continuous, non-hierarchic
-finite element families. Additionally, p-refinement of NEDELEC_ONE is not
-supported. Consequently, by default we disable p-refinement of the bollowing
+finite element families. Additionally, p-refinement of `NEDELEC_ONE` is not
+supported. Consequently, by default we disable p-refinement of the following
 bases: `LAGRANGE`, `NEDELEC_ONE`, `LAGRANGE_VEC`, `CLOUGH`, `BERNSTEIN`, and
 `RATIONAL_BERNSTEIN`. Users can control what families are disabled for
 p-refinement by setting the `disable_p_refinement_for_families` parameter.
diff --git a/framework/doc/content/syntax/ICs/index.md b/framework/doc/content/syntax/ICs/index.md
index fcfbb7d67760..55369db83167 100644
--- a/framework/doc/content/syntax/ICs/index.md
+++ b/framework/doc/content/syntax/ICs/index.md
@@ -37,9 +37,9 @@ these DOFs, the initial condition system has an optional override for supplying
 ## Inspecting Current Node or Element Pointers
 
 The initial condition system uses a generic projection algorithm for setting the initial condition
-for each supported discritization scheme. In the general case, the projection system may choose
+for each supported discretization scheme. In the general case, the projection system may choose
 to sample anywhere within the domain and not necessarily right on a mesh node or at an element center
-position. However, for common FE discritizations suchs as Lagrange, all of the initial condition
+position. However, for common FE discretizations such as Lagrange, all of the initial condition
 samples are taken at nodes. To support these common cases, InitialCondition derived objects have
 access to pointers to both current nodes and current elements. These will be non-null when
 samples are taken at the corresponding mesh entity and null otherwise.
diff --git a/framework/doc/content/syntax/Limiters/index.md b/framework/doc/content/syntax/Limiters/index.md
index 47be99270530..a08a469d9bce 100644
--- a/framework/doc/content/syntax/Limiters/index.md
+++ b/framework/doc/content/syntax/Limiters/index.md
@@ -23,7 +23,7 @@ TV(u^{n+1}) \leq TV(u^n)
 ## Limiting Process
 
 Borrowing notation from [!citep](greenshields2010implementation), we will now
-discuss computation of limited quanties, represented by $\bm{\Psi}_{f\pm}$ where
+discuss computation of limited quantities, represented by $\bm{\Psi}_{f\pm}$ where
 $+$ represents one side of a face, and $-$ represents the other side. To be
 clear about notation: the equations that follow will have a lot of $\pm$ and
 $\mp$. When computing the top quantity (e.g. $+$ for $\pm$) we select the top
diff --git a/framework/doc/content/syntax/Mesh/Partitioner/index.md b/framework/doc/content/syntax/Mesh/Partitioner/index.md
index 395d1fc9d589..5755fdfc1838 100644
--- a/framework/doc/content/syntax/Mesh/Partitioner/index.md
+++ b/framework/doc/content/syntax/Mesh/Partitioner/index.md
@@ -5,7 +5,7 @@ to split up a mesh among two or more processors. There are several partitioners
 available in both PETSc and libMesh which can be directly dialed up through the
 MOOSE input file via the [/LibmeshPartitioner.md] and [/PetscExternalPartitioner.md]
 objects. Custom Partitioners may be built by inheriting from MoosePartitioner.md
-and overriding the special `_do_parition()` method (from libMesh's partitioner).
+and overriding the special `_do_partition()` method (from libMesh's partitioner).
 
 !syntax list /Mesh/Partitioner objects=True actions=False subsystems=False