diff --git a/docs/src/main/tut/datatypes/const.md b/docs/src/main/tut/datatypes/const.md
index d047303a30..39d4caa420 100644
--- a/docs/src/main/tut/datatypes/const.md
+++ b/docs/src/main/tut/datatypes/const.md
@@ -29,7 +29,7 @@ Because the second type parameter is not used in the data type, the type paramet
 
 ## Why do we care?
 It would seem `Const` gives us no benefit over a data type that would simply not have the second type parameter.
-However, while we don't directly use the second type parameter, it's existence becomes useful in certain contexts.
+However, while we don't directly use the second type parameter, its existence becomes useful in certain contexts.
 
 ### Example 1: Lens
 The following is heavily inspired by [Julien Truffaut](https://github.com/julien-truffaut)'s
diff --git a/docs/src/main/tut/datatypes/kleisli.md b/docs/src/main/tut/datatypes/kleisli.md
index ad5108e9c8..27923024af 100644
--- a/docs/src/main/tut/datatypes/kleisli.md
+++ b/docs/src/main/tut/datatypes/kleisli.md
@@ -56,7 +56,7 @@ The output type of `parse` is `Option[Int]` whereas the input type of `reciproca
 This is where `Kleisli` comes into play.
 
 ## Kleisli
-At it's core, `Kleisli[F[_], A, B]` is just a wrapper around the function `A => F[B]`. Depending on the
+At its core, `Kleisli[F[_], A, B]` is just a wrapper around the function `A => F[B]`. Depending on the
 properties of the `F[_]`, we can do different things with `Kleisli`s. For instance, if `F[_]` has a
 `FlatMap[F]` instance (we can call `flatMap` on `F[A]` values), we can
 compose two `Kleisli`s much like we can two functions.
@@ -215,7 +215,7 @@ Functional programming advocates the creation of programs and modules by composi
 philosophy intentionally mirrors that of function composition - write many small functions, and compose them
 to build larger ones. After all, our programs are just functions.
 
-Let's look at some example modules, where each module has it's own configuration that is validated by a function.
+Let's look at some example modules, where each module has its own configuration that is validated by a function.
 If the configuration is good, we return a `Some` of the module, otherwise a `None`. This example uses `Option` for
 simplicity - if you want to provide error messages or other failure context, consider using `Either` instead.
 
diff --git a/docs/src/main/tut/typeclasses/imports.md b/docs/src/main/tut/typeclasses/imports.md
index 8e4c38fe01..43bcb16b12 100644
--- a/docs/src/main/tut/typeclasses/imports.md
+++ b/docs/src/main/tut/typeclasses/imports.md
@@ -53,7 +53,7 @@ The first import pulls the `Semigroup` instance for String into the scope, while
 You can also import all syntax or all instances by importing `cats.syntax.all._` or `cats.instances.all._` respectively.
 
 For data types included in cats (i.e. data structure from the `cats.data` package), all type class instances are bundled with their implementation and therefore do not need to be imported separately.
-For example, if we wanted to import `NonEmptyList` from the `cats.data` package and use it's `SemigroupK` instance, we would not need to specifically import the instance:
+For example, if we wanted to import `NonEmptyList` from the `cats.data` package and use its `SemigroupK` instance, we would not need to specifically import the instance:
 
 ```tut:book
 import cats.data.NonEmptyList
diff --git a/docs/src/main/tut/typeclasses/invariantmonoidal.md b/docs/src/main/tut/typeclasses/invariantmonoidal.md
index c238f359bc..a8fdb49c4e 100644
--- a/docs/src/main/tut/typeclasses/invariantmonoidal.md
+++ b/docs/src/main/tut/typeclasses/invariantmonoidal.md
@@ -189,7 +189,7 @@ fooCodec.read(fooCodec.write(foo)) == ((Some(foo), List()))
 
 # `InvariantMonoidal` as a generalization of `Invariant`
 
-To better understand the motivations behind the `InvariantMonoidal` type class, we show how one could naturally arrive to it's definition by generalizing the concept of `Invariant` functor. This reflection is analogous to the one presented in [Free Applicative Functors by Paolo Capriotti](http://www.paolocapriotti.com/assets/applicative.pdf) to show how [`Applicative`](applicative.html) are a generalization of [`Functor`](functor.html).
+To better understand the motivations behind the `InvariantMonoidal` type class, we show how one could naturally arrive to its definition by generalizing the concept of `Invariant` functor. This reflection is analogous to the one presented in [Free Applicative Functors by Paolo Capriotti](http://www.paolocapriotti.com/assets/applicative.pdf) to show how [`Applicative`](applicative.html) are a generalization of [`Functor`](functor.html).
 
 Given an `Invariant[F]` instance for a certain *context* `F[_]`, its `imap` method gives a way to lift two *unary* pure functions `A => B` and `B => A` into *contextualized* functions `F[A] => F[B]`. But what about functions of other arity?