diff --git a/README.md b/README.md
index 0da4d52fc..c4ac913d3 100644
--- a/README.md
+++ b/README.md
@@ -439,21 +439,21 @@ velocity.dy = 0.;
 ```
 
 In case users want to assign a component to an entity, but it's unknown whether
-the entity already has it or not, `accomodate` does the work in a single call
+the entity already has it or not, `accommodate` does the work in a single call
 (there is a performance penalty to pay for this mainly due to the fact that it
 has to check if the entity already has the given component or not):
 
 ```cpp
-registry.accomodate<Position>(entity, 0., 0.);
+registry.accommodate<Position>(entity, 0., 0.);
 
 // ...
 
-Velocity &velocity = registry.accomodate<Velocity>(entity);
+Velocity &velocity = registry.accommodate<Velocity>(entity);
 velocity.dx = 0.;
 velocity.dy = 0.;
 ```
 
-Note that `accomodate` is a sliglhty faster alternative for the following
+Note that `accommodate` is a slightly faster alternative for the following
 `if`/`else` statement and nothing more:
 
 ```cpp
@@ -1623,7 +1623,7 @@ There are two types of signal handlers in `EnTT`, internally called _managed_
 and _unmanaged_.<br/>
 They differ in the way they work around the tradeoff between performance, memory
 usage and safety. Managed listeners must be wrapped in an `std::shared_ptr` and
-the sink will take care of disconneting them whenever they die. Unmanaged
+the sink will take care of disconnecting them whenever they die. Unmanaged
 listeners can be any kind of objects and the client is in charge of connecting
 and disconnecting them from a sink to avoid crashes due to different lifetimes.
 
@@ -1998,7 +1998,7 @@ As an example:
 
 ```cpp
 dispatcher.trigger<AnEvent>(42);
-dispatcher.trigget<AnotherEvent>();
+dispatcher.trigger<AnotherEvent>();
 ```
 
 Listeners are invoked immediately, order of execution isn't guaranteed. This
diff --git a/src/entt/entity/actor.hpp b/src/entt/entity/actor.hpp
index 1980f8643..259a0220c 100644
--- a/src/entt/entity/actor.hpp
+++ b/src/entt/entity/actor.hpp
@@ -66,7 +66,7 @@ struct Actor {
      */
     template<typename Component, typename... Args>
     Component & set(Args &&... args) {
-        return reg.template accomodate<Component>(entity, std::forward<Args>(args)...);
+        return reg.template accommodate<Component>(entity, std::forward<Args>(args)...);
     }
 
     /**
diff --git a/src/entt/entity/registry.hpp b/src/entt/entity/registry.hpp
index 913ee0927..a9f537876 100644
--- a/src/entt/entity/registry.hpp
+++ b/src/entt/entity/registry.hpp
@@ -775,7 +775,7 @@ public:
      * }
      * @endcode
      *
-     * Prefer this function anyway because it has slighlty better
+     * Prefer this function anyway because it has slightly better
      * performance.
      *
      * @warning
@@ -790,7 +790,7 @@ public:
      * @return A reference to the newly created component.
      */
     template<typename Component, typename... Args>
-    Component & accomodate(entity_type entity, Args &&... args) {
+    Component & accommodate(entity_type entity, Args &&... args) {
         assert(valid(entity));
         auto &cpool = ensure<Component>();
 
@@ -802,7 +802,7 @@ public:
     /**
      * @brief Sorts the pool of entities for the given component.
      *
-     * The order of the elements in a pool is highly affected by assignements
+     * The order of the elements in a pool is highly affected by assignments
      * of components to entities and deletions. Components are arranged to
      * maximize the performance during iterations and users should not make any
      * assumption on the order.<br/>
@@ -830,7 +830,7 @@ public:
     /**
      * @brief Sorts two pools of components in the same way.
      *
-     * The order of the elements in a pool is highly affected by assignements
+     * The order of the elements in a pool is highly affected by assignments
      * of components to entities and deletions. Components are arranged to
      * maximize the performance during iterations and users should not make any
      * assumption on the order.
@@ -1024,7 +1024,7 @@ public:
      * As a rule of thumb, storing a view should never be an option.
      *
      * Standard views do their best to iterate the smallest set of candidate
-     * entites. In particular:
+     * entities. In particular:
      *
      * * Single component views are incredibly fast and iterate a packed array
      * of entities, all of which has the given component.
@@ -1062,7 +1062,7 @@ public:
      * requested.<br/>
      * To avoid costly operations, internal data structures for persistent views
      * can be prepared with this function. Just use the same set of components
-     * that would have been used otherwise to contruct the view.
+     * that would have been used otherwise to construct the view.
      *
      * @tparam Component Types of components used to prepare the view.
      */
@@ -1121,7 +1121,7 @@ public:
      * initialization.<br/>
      * As a rule of thumb, storing a view should never be an option.
      *
-     * Persistent views are the right choice to iterate entites when the number
+     * Persistent views are the right choice to iterate entities when the number
      * of components grows up and the most of the entities have all the given
      * components.<br/>
      * However they have also drawbacks:
diff --git a/src/entt/entity/view.hpp b/src/entt/entity/view.hpp
index d3abdb8e8..d38bd1db2 100644
--- a/src/entt/entity/view.hpp
+++ b/src/entt/entity/view.hpp
@@ -27,7 +27,7 @@ class Registry;
  *
  * A persistent view returns all the entities and only the entities that have
  * at least the given components. Moreover, it's guaranteed that the entity list
- * is thightly packed in memory for fast iterations.<br/>
+ * is tightly packed in memory for fast iterations.<br/>
  * In general, persistent views don't stay true to the order of any set of
  * components unless users explicitly sort them.
  *
@@ -710,7 +710,7 @@ private:
  *
  * Single component views are specialized in order to get a boost in terms of
  * performance. This kind of views can access the underlying data structure
- * directly and avoid superflous checks.<br/>
+ * directly and avoid superfluous checks.<br/>
  * Order of elements during iterations are highly dependent on the order of the
  * underlying data structure. See SparseSet and its specializations for more
  * details.
diff --git a/src/entt/locator/locator.hpp b/src/entt/locator/locator.hpp
index 8765b8f9a..5e9b573fa 100644
--- a/src/entt/locator/locator.hpp
+++ b/src/entt/locator/locator.hpp
@@ -14,7 +14,7 @@ namespace entt {
  * @brief Service locator, nothing more.
  *
  * A service locator can be used to do what it promises: locate services.<br/>
- * Usually service locators are tighly bound to the services they expose and
+ * Usually service locators are tightly bound to the services they expose and
  * thus it's hard to define a general purpose class to do that. This template
  * based implementation tries to fill the gap and to get rid of the burden of
  * defining a different specific locator for each application.
diff --git a/src/entt/signal/dispatcher.hpp b/src/entt/signal/dispatcher.hpp
index e20e1a9b3..4343f4068 100644
--- a/src/entt/signal/dispatcher.hpp
+++ b/src/entt/signal/dispatcher.hpp
@@ -127,7 +127,7 @@ public:
      * automatically detected and unregistered if available.
      *
      * @warning
-     * Disonnecting a listener during an update may lead to unexpected behavior.
+     * Disconnecting a listener during an update may lead to unexpected behavior.
      * Unregister listeners before or after invoking the update if possible.
      *
      * @tparam Event Type of event from which to disconnect the function.
diff --git a/test/entt/core/hashed_string.cpp b/test/entt/core/hashed_string.cpp
index 6c3b434cd..b3f7872f8 100644
--- a/test/entt/core/hashed_string.cpp
+++ b/test/entt/core/hashed_string.cpp
@@ -22,7 +22,7 @@ constexpr bool ref(const char (&str)[N]) {
 }
 
 TEST(HashedString, Constexprness) {
-    // how would you test a constepxr otherwise?
+    // how would you test a constexpr otherwise?
     static_assert(ptr("foo"), "!");
     static_assert(ref("bar"), "!");
     ASSERT_TRUE(true);
diff --git a/test/entt/entity/registry.cpp b/test/entt/entity/registry.cpp
index a1216499a..2cd06c831 100644
--- a/test/entt/entity/registry.cpp
+++ b/test/entt/entity/registry.cpp
@@ -56,8 +56,8 @@ TEST(DefaultRegistry, Functionalities) {
 
     auto e2 = registry.create();
 
-    registry.accomodate<int>(e2, registry.get<int>(e0));
-    registry.accomodate<char>(e2, registry.get<char>(e0));
+    registry.accommodate<int>(e2, registry.get<int>(e0));
+    registry.accommodate<char>(e2, registry.get<char>(e0));
 
     ASSERT_TRUE(registry.has<int>(e2));
     ASSERT_TRUE(registry.has<char>(e2));
@@ -75,8 +75,8 @@ TEST(DefaultRegistry, Functionalities) {
     ASSERT_NO_THROW(registry.replace<int>(e0, 0));
     ASSERT_EQ(registry.get<int>(e0), 0);
 
-    ASSERT_NO_THROW(registry.accomodate<int>(e0, 1));
-    ASSERT_NO_THROW(registry.accomodate<int>(e1, 1));
+    ASSERT_NO_THROW(registry.accommodate<int>(e0, 1));
+    ASSERT_NO_THROW(registry.accommodate<int>(e1, 1));
     ASSERT_EQ(static_cast<const entt::DefaultRegistry &>(registry).get<int>(e0), 1);
     ASSERT_EQ(static_cast<const entt::DefaultRegistry &>(registry).get<int>(e1), 1);
 
diff --git a/test/mod/mod.cpp b/test/mod/mod.cpp
index 17cae1b36..3131e4e3d 100644
--- a/test/mod/mod.cpp
+++ b/test/mod/mod.cpp
@@ -22,7 +22,7 @@ struct DuktapeRuntime {
 template<typename Comp>
 duk_ret_t set(duk_context *ctx, entt::DefaultRegistry &registry) {
     const auto entity = duk_require_uint(ctx, 0);
-    registry.accomodate<Comp>(entity);
+    registry.accommodate<Comp>(entity);
     return 0;
 }
 
@@ -31,7 +31,7 @@ duk_ret_t set<Position>(duk_context *ctx, entt::DefaultRegistry &registry) {
     const auto entity = duk_require_uint(ctx, 0);
     const auto x = duk_require_number(ctx, 2);
     const auto y = duk_require_number(ctx, 3);
-    registry.accomodate<Position>(entity, x, y);
+    registry.accommodate<Position>(entity, x, y);
     return 0;
 }