diff --git a/beacon_chain/sync/README.md b/beacon_chain/sync/README.md
index 162aa4eb1..282615f1c 100644
--- a/beacon_chain/sync/README.md
+++ b/beacon_chain/sync/README.md
@@ -21,7 +21,7 @@ Blocks are received by batch:
 - in case of failure:
   - `push(SyncQueue, SyncRequest)` is called to reschedule the sync request.
 
-Every second when sync is not in progress, the beacon node will ask the RequestManager to download all missing blocks currently in quarantaine.
+Every second when sync is not in progress, the beacon node will ask the RequestManager to download all missing blocks currently in quarantine.
 - via `handleMissingBlocks`
 - which calls `fetchAncestorBlocks`
 - which asynchronously enqueue the request in the SharedBlockQueue `AsyncQueue[BlockEntry]`.
diff --git a/docs/e2store.md b/docs/e2store.md
index 725fda503..16712b5a1 100644
--- a/docs/e2store.md
+++ b/docs/e2store.md
@@ -327,7 +327,7 @@ An era is typically `8192` slots (in the mainnet configuration), or roughly 27.3
 
 ## What happens after the merge?
 
-Era files will store execution block contents, but not execution states (these are too large) - a full era history thus gives the full ethereum history from the merge onwards for convenient cold storage. Work is underway to similarily cover the rest of history.
+Era files will store execution block contents, but not execution states (these are too large) - a full era history thus gives the full ethereum history from the merge onwards for convenient cold storage. Work is underway to similarly cover the rest of history.
 
 ## Which state should be stored in the era file?
 
diff --git a/docs/the_nimbus_book/src/web3signer.md b/docs/the_nimbus_book/src/web3signer.md
index e5f773461..c8a7f0b12 100644
--- a/docs/the_nimbus_book/src/web3signer.md
+++ b/docs/the_nimbus_book/src/web3signer.md
@@ -40,7 +40,7 @@ The fields have the following semantics:
 5. `remote` - An URL of a remote signing server.
 6. `remotes` - A [distributed keystore](#distributed-keystores) configuration including two or more remote signing servers.
 7. `ignore_ssl_verification` - An optional boolean flag allowing the use of self-signed certificates by the signing server.
-8. `proven_block_properties` - When the `verifying-web3signer` type is used, this is a list of locations withing the SSZ block body for which the block signing requests will contain additional Merkle proofs, allowing the signer to verify certain details about the signed blocks (e.g. the `fee_recipient` value).
+8. `proven_block_properties` - When the `verifying-web3signer` type is used, this is a list of locations within the SSZ block body for which the block signing requests will contain additional Merkle proofs, allowing the signer to verify certain details about the signed blocks (e.g. the `fee_recipient` value).
 
 !!! info
     The current version of the remote keystore format is `3` which adds support for the experimental [verifying web3signer setups](#verifying-web3signer).
diff --git a/ncli/README.md b/ncli/README.md
index 72aae6559..f645007ed 100644
--- a/ncli/README.md
+++ b/ncli/README.md
@@ -1,6 +1,6 @@
 # Introduction
 
-`ncli` is a set of low level / debugging tools to interact with the nimbus [beacon chain specification](https://github.com/ethereum/consensus-specs/tree/dev/specs) implementation, simliar to [zcli](https://github.com/protolambda/zcli). With it, you explore SSZ, make state transitions and compute hash tree roots.
+`ncli` is a set of low level / debugging tools to interact with the nimbus [beacon chain specification](https://github.com/ethereum/consensus-specs/tree/dev/specs) implementation, similar to [zcli](https://github.com/protolambda/zcli). With it, you explore SSZ, make state transitions and compute hash tree roots.
 
 # Tools