diff --git a/README.md b/README.md
index f0b46bbfe..0d7b1366d 100644
--- a/README.md
+++ b/README.md
@@ -25,7 +25,7 @@ Octonian algebras, you've come to the right place.
 
 [Symbols in SymbolicUtils](https://symbolicutils.juliasymbolics.org/#creating_symbolic_expressions) carry type information. Operations on them propagate this information. [A rule-based rewriting language](https://symbolicutils.juliasymbolics.org/rewrite/#rule-based_rewriting) can be used to find subexpressions that satisfy arbitrary conditions and apply arbitrary transformations on the matches. The library also contains a set of useful [simplification](https://juliasymbolics.github.io/SymbolicUtils.jl/#simplification) rules for expressions of numeric symbols and numbers. These can be remixed and extended for special purposes.
 
-If you are a Julia package develper in need of a rule rewriting system for your own types, have a look at the [interfacing guide](https://symbolicutils.juliasymbolics.org/interface/).
+If you are a Julia package developer in need of a rule rewriting system for your own types, have a look at the [interfacing guide](https://symbolicutils.juliasymbolics.org/interface/).
 
 
 ### "I don't want to read your manual, just show me some cool code"
diff --git a/docs/src/manual/representation.md b/docs/src/manual/representation.md
index 1c8dde526..b0b1585dd 100644
--- a/docs/src/manual/representation.md
+++ b/docs/src/manual/representation.md
@@ -2,7 +2,7 @@
 
 Performance of symbolic simplification depends on the datastructures used to represent terms. Efficient datastructures often have the advantage of automatic simplification, and of efficient storage.
 
-The most basic term representation simply holds a function call and stores the function and the arguments it is called with. This is done by the `Term` type in SymbolicUtils. Functions that aren't commutative or associative, such as `sin` or `hypot` are stored as `Term`s. Commutatative and associative operations like `+`, `*`, and their supporting operations like `-`, `/` and `^`, when used on terms of type `<:Number`, stand to gain from the use of more efficient datastrucutres.
+The most basic term representation simply holds a function call and stores the function and the arguments it is called with. This is done by the `Term` type in SymbolicUtils. Functions that aren't commutative or associative, such as `sin` or `hypot` are stored as `Term`s. Commutative and associative operations like `+`, `*`, and their supporting operations like `-`, `/` and `^`, when used on terms of type `<:Number`, stand to gain from the use of more efficient datastrucutres.
 
 All term representations must support `operation` and `arguments` functions. And they must define `istree` to return `true` when called with an instance of the type. Generic term-manipulation programs such as the rule-based rewriter make use of this interface to inspect expressions. In this way, the interface wins back the generality lost by having a zoo of term representations instead of one. (see [interface](/interface/) section for more on this.)
 
@@ -16,7 +16,7 @@ Similarly, $x_1^{m_1}x_2^{m_2}...x_{m_n}$ is represented by
 
 Note that `Add` and `Mul` types perform a preliminary simplification which suffices to simplify numeric expressions to a large extent during construction.
 
-$p / q$ is represented by `Div(p, q)`. The result of `*` on `Div` is maintainted as a `Div`. For example, `Div(p_1, q_1) * Div(p_2, q_2)` results in `Div(p_1 * p_2, q_1 * q_2)` and so on. The effect is, in `Div(p, q)`, `p` or `q` or, if they are Mul, any of their multiplicands is not a Div. So `Mul`s must always be nested inside a `Div` and can never show up immediately wrapping it. This rule sets up an expression so that it helps the `simplify_fractions` procedure described two sections below.
+$p / q$ is represented by `Div(p, q)`. The result of `*` on `Div` is maintained as a `Div`. For example, `Div(p_1, q_1) * Div(p_2, q_2)` results in `Div(p_1 * p_2, q_1 * q_2)` and so on. The effect is, in `Div(p, q)`, `p` or `q` or, if they are Mul, any of their multiplicands is not a Div. So `Mul`s must always be nested inside a `Div` and can never show up immediately wrapping it. This rule sets up an expression so that it helps the `simplify_fractions` procedure described two sections below.
 
 
 ### Polynomial representation
diff --git a/docs/src/manual/rewrite.md b/docs/src/manual/rewrite.md
index 5397fbbe6..c1be3187d 100644
--- a/docs/src/manual/rewrite.md
+++ b/docs/src/manual/rewrite.md
@@ -74,7 +74,7 @@ Notice that the expression was autosimplified before application of the rule.
 
 Matcher pattern may contain slot variables with attached predicates, written as `~x::f` where `f` is a function that takes a matched expression and returns a boolean value. Such a slot will be considered a match only if `f` returns true.
 
-Similarly `~~x::g` is a way of attaching a predicate `g` to a segment variable. In the case of segment variables `g` gets a vector of 0 or more expressions and must return a boolean value. If the same slot or segment variable appears twice in the matcher pattern, then at most one of the occurance should have a predicate.
+Similarly `~~x::g` is a way of attaching a predicate `g` to a segment variable. In the case of segment variables `g` gets a vector of 0 or more expressions and must return a boolean value. If the same slot or segment variable appears twice in the matcher pattern, then at most one of the occurrence should have a predicate.
 
 For example,
 
@@ -133,7 +133,7 @@ acpyid = @acrule sin(~x)^2 + cos(~x)^2 => 1
 acpyid(cos(x)^2 + sin(x)^2 + 2cos(x)*sin(x))
 ```
 
-It has been some work. Fortunately rules may be [chained together](#chaining rewriters) into more sophisticated rewirters to avoid manual application of the rules.
+It has been some work. Fortunately rules may be [chained together](#chaining rewriters) into more sophisticated rewriters to avoid manual application of the rules.
 
 
 ## Composing rewriters
diff --git a/page/config.md b/page/config.md
index 4b1794024..c24f6048f 100644
--- a/page/config.md
+++ b/page/config.md
@@ -114,7 +114,7 @@ NOTE:
                         "github" or "atom-one-dark"; use lower case and replace
                         spaces with `-`.
   - code_border_radius: how rounded the corners of code blocks should be
-  - code_output_indent: how much left-identation to add for "output blocks"
+  - code_output_indent: how much left-indentation to add for "output blocks"
                         (results of the evaluation of code blocks), use 0 if
                         you don't want indentation.
 -->
diff --git a/page/interface.md b/page/interface.md
index 894ddd821..88a77c80a 100644
--- a/page/interface.md
+++ b/page/interface.md
@@ -22,7 +22,7 @@ with SymbolicUtils.jl
 
 Check if `x` represents an expression tree. If returns true,
 it will be assumed that `operation(::T)` and `arguments(::T)`
-methods are defined. Definining these three should allow use
+methods are defined. Defining these three should allow use
 of `simplify` on custom types. Optionally `symtype(x)` can be
 defined to return the expected type of the symbolic expression.
 
diff --git a/page/representation.md b/page/representation.md
index b8932b5f0..aa07ee4a6 100644
--- a/page/representation.md
+++ b/page/representation.md
@@ -2,7 +2,7 @@
 
 Performance of symbolic simplification depends on the datastructures used to represent terms. Efficient datastructures often have the advantage of automatic simplification, and of efficient storage.
 
-The most basic term representation simply holds a function call and stores the function and the arguments it is called with. This is done by the `Term` type in SymbolicUtils. Functions that aren't commutative or associative, such as `sin` or `hypot` are stored as `Term`s. Commutatative and associative operations like `+`, `*`, and their supporting operations like `-`, `/` and `^`, when used on terms of type `<:Number`, stand to gain from the use of more efficient datastrucutres.
+The most basic term representation simply holds a function call and stores the function and the arguments it is called with. This is done by the `Term` type in SymbolicUtils. Functions that aren't commutative or associative, such as `sin` or `hypot` are stored as `Term`s. Commutative and associative operations like `+`, `*`, and their supporting operations like `-`, `/` and `^`, when used on terms of type `<:Number`, stand to gain from the use of more efficient datastrucutres.
 
 All term representations must support `operation` and `arguments` functions. And they must define `istree` to return `true` when called with an instance of the type. Generic term-manipulation programs such as the rule-based rewriter make use of this interface to inspect expressions. In this way, the interface wins back the generality lost by having a zoo of term representations instead of one. (see [interface](/interface/) section for more on this.)
 
@@ -16,7 +16,7 @@ Similarly, $x_1^{m_1}x_2^{m_2}...x_{m_n}$ is represented by
 
 Note that `Add` and `Mul` types perform a preliminary simplification which suffices to simplify numeric expressions to a large extent during construction.
 
-$p / q$ is represented by `Div(p, q)`. The result of `*` on `Div` is maintainted as a `Div`. For example, `Div(p_1, q_1) * Div(p_2, q_2)` results in `Div(p_1 * p_2, q_1 * q_2)` and so on. The effect is, in `Div(p, q)`, `p` or `q` or, if they are Mul, any of their multiplicands is not a Div. So `Mul`s must always be nested inside a `Div` and can never show up immediately wrapping it. This rule sets up an expression so that it helps the `simplify_fractions` procedure described two sections below.
+$p / q$ is represented by `Div(p, q)`. The result of `*` on `Div` is maintained as a `Div`. For example, `Div(p_1, q_1) * Div(p_2, q_2)` results in `Div(p_1 * p_2, q_1 * q_2)` and so on. The effect is, in `Div(p, q)`, `p` or `q` or, if they are Mul, any of their multiplicands is not a Div. So `Mul`s must always be nested inside a `Div` and can never show up immediately wrapping it. This rule sets up an expression so that it helps the `simplify_fractions` procedure described two sections below.
 
 
 ### Polynomial representation
diff --git a/page/rewrite.md b/page/rewrite.md
index 5397fbbe6..c1be3187d 100644
--- a/page/rewrite.md
+++ b/page/rewrite.md
@@ -74,7 +74,7 @@ Notice that the expression was autosimplified before application of the rule.
 
 Matcher pattern may contain slot variables with attached predicates, written as `~x::f` where `f` is a function that takes a matched expression and returns a boolean value. Such a slot will be considered a match only if `f` returns true.
 
-Similarly `~~x::g` is a way of attaching a predicate `g` to a segment variable. In the case of segment variables `g` gets a vector of 0 or more expressions and must return a boolean value. If the same slot or segment variable appears twice in the matcher pattern, then at most one of the occurance should have a predicate.
+Similarly `~~x::g` is a way of attaching a predicate `g` to a segment variable. In the case of segment variables `g` gets a vector of 0 or more expressions and must return a boolean value. If the same slot or segment variable appears twice in the matcher pattern, then at most one of the occurrence should have a predicate.
 
 For example,
 
@@ -133,7 +133,7 @@ acpyid = @acrule sin(~x)^2 + cos(~x)^2 => 1
 acpyid(cos(x)^2 + sin(x)^2 + 2cos(x)*sin(x))
 ```
 
-It has been some work. Fortunately rules may be [chained together](#chaining rewriters) into more sophisticated rewirters to avoid manual application of the rules.
+It has been some work. Fortunately rules may be [chained together](#chaining rewriters) into more sophisticated rewriters to avoid manual application of the rules.
 
 
 ## Composing rewriters
diff --git a/src/SymbolicUtils.jl b/src/SymbolicUtils.jl
index 1fb7d777a..fab2b8645 100644
--- a/src/SymbolicUtils.jl
+++ b/src/SymbolicUtils.jl
@@ -63,7 +63,7 @@ include("substitute.jl")
 include("code.jl")
 
 
-# ADjoints
+# Adjoints
 include("adjoints.jl")
 
 end # module
diff --git a/src/code.jl b/src/code.jl
index 23ca867e4..7c647ba9c 100644
--- a/src/code.jl
+++ b/src/code.jl
@@ -448,7 +448,7 @@ You can define:
 
 # and
 
-@inlline function create_array(::Type{<:MyArray}, T, ::Val{dims}, elems...) where dims
+@inline function create_array(::Type{<:MyArray}, T, ::Val{dims}, elems...) where dims
 ```
 
 which creates an array of size `dims` using the elements `elems` and eltype `T`, to allow
diff --git a/src/interface.jl b/src/interface.jl
index 264949cf3..255ef584f 100644
--- a/src/interface.jl
+++ b/src/interface.jl
@@ -45,8 +45,8 @@ function arguments end
 """
   unsorted_arguments(x::T)
 
-If x is a term satisfying `istree(x)` and your term type `T` orovides
-and optimized implementation for storing the arguments, this function can 
+If x is a term satisfying `istree(x)` and your term type `T` provides
+an optimized implementation for storing the arguments, this function can
 be used to retrieve the arguments when the order of arguments does not matter 
 but the speed of the operation does.
 """
diff --git a/src/rule.jl b/src/rule.jl
index 8f61ab527..a872222e6 100644
--- a/src/rule.jl
+++ b/src/rule.jl
@@ -169,7 +169,7 @@ Creates a `Rule` object. A rule object is callable, and  takes an expression and
 it if it matches the LHS pattern to the RHS pattern, returns `nothing` otherwise.
 The rule language is described below.
 
-LHS can be any possibly nested function call expression where any of the arugments can
+LHS can be any possibly nested function call expression where any of the arguments can
 optionally be a Slot (`~x`) or a Segment (`~~x`) (described below).
 
 If an expression matches LHS entirely, then it is rewritten to the pattern in the RHS
diff --git a/src/types.jl b/src/types.jl
index b3ba5dc0c..c646ec47c 100644
--- a/src/types.jl
+++ b/src/types.jl
@@ -871,7 +871,7 @@ end
 """
     promote_symtype(f::FnType{X,Y}, arg_symtypes...)
 
-The output symtype of applying variable `f` to arugments of symtype `arg_symtypes...`.
+The output symtype of applying variable `f` to arguments of symtype `arg_symtypes...`.
 if the arguments are of the wrong type then this function will error.
 """
 function promote_symtype(f::BasicSymbolic{<:FnType{X,Y}}, args...) where {X, Y}
diff --git a/test/fuzzlib.jl b/test/fuzzlib.jl
index adac553cf..03ebcf0f6 100644
--- a/test/fuzzlib.jl
+++ b/test/fuzzlib.jl
@@ -61,7 +61,7 @@ const bool_spec = let
 
     fns = vcat(1 .=> [(!), (~)],
                2 .=> [(|), (&), xor],
-               3 .=> [ifelse]) # cond will still stay in bool by condtruction
+               3 .=> [ifelse]) # cond will still stay in bool by construction
 
     (leaves=bool_leaf_funcs,
      funcs=fns,