diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index bf3d6ef8ce8d..f1871cab1c39 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -201,7 +201,7 @@ follow the Carbon documentation and coding styles.
 
     -   New features should have a documented design that has been approved
         through the [evolution process](docs/project/evolution.md). This
-        includes modifications to pre-existing designs.
+        includes modifications to preexisting designs.
     -   Bug fixes and mechanical improvements don't need this.
     -   All new features include unit tests, as they help to (a) document and
         validate concrete usage of the feature and its edge cases, and (b) guard
diff --git a/README.md b/README.md
index b2a6af0bb685..ec2c020600bc 100644
--- a/README.md
+++ b/README.md
@@ -296,7 +296,7 @@ contribute.
     [our Carbon release post on GitHub](https://github.com/carbon-language/carbon-lang/discussions/1020)
     and [star carbon-lang](https://github.com/carbon-language/carbon-lang).
 -   To join the design discussion, join our
-    [our Github forum](https://github.com/carbon-language/carbon-lang/discussions).
+    [our GitHub forum](https://github.com/carbon-language/carbon-lang/discussions).
 -   See our [code of conduct](CODE_OF_CONDUCT.md) and
     [contributing guidelines](CONTRIBUTING.md) for information about the Carbon
     development community.
diff --git a/bazel/cc_toolchains/clang_cc_toolchain_config.bzl b/bazel/cc_toolchains/clang_cc_toolchain_config.bzl
index 3fe9298b0e62..2ed6595e2952 100644
--- a/bazel/cc_toolchains/clang_cc_toolchain_config.bzl
+++ b/bazel/cc_toolchains/clang_cc_toolchain_config.bzl
@@ -461,7 +461,7 @@ def _impl(ctx):
                 "-fsanitize=address,undefined,nullability",
                 "-fsanitize-address-use-after-scope",
                 # We don't need the recovery behavior of UBSan as we expect
-                # builds to be clean. Not recoverying is a bit cheaper.
+                # builds to be clean. Not recovering is a bit cheaper.
                 "-fno-sanitize-recover=undefined",
                 # Don't embed the full path name for files. This limits the size
                 # and combined with line numbers is unlikely to result in many
diff --git a/docs/design/README.md b/docs/design/README.md
index 6080df7f9f4d..4a7a3d71d152 100644
--- a/docs/design/README.md
+++ b/docs/design/README.md
@@ -1401,8 +1401,8 @@ two methods `Distance` and `Offset`:
 -   Methods are defined as class functions with a `me` parameter inside square
     brackets `[`...`]` before the regular explicit parameter list in parens
     `(`...`)`.
--   Methods are called using using the member syntax, `origin.Distance(`...`)`
-    and `origin.Offset(`...`)`.
+-   Methods are called using the member syntax, `origin.Distance(`...`)` and
+    `origin.Offset(`...`)`.
 -   `Distance` computes and returns the distance to another point, without
     modifying the `Point`. This is signified using `[me: Self]` in the method
     declaration.
@@ -1440,7 +1440,7 @@ base class MyBaseClass { ... }
 ```
 
 Either kind of base class may be _extended_ to get a _derived class_. Derived
-classes are final unless they are themselved declared `base` or `abstract`.
+classes are final unless they are themselves declared `base` or `abstract`.
 Classes may only extend a single class. Carbon only supports single inheritance,
 and will use mixins instead of multiple inheritance.
 
@@ -1458,8 +1458,8 @@ by one of these three keywords:
 
 -   A method marked `virtual` has a definition in this class but not in any
     base.
--   A method marked `abstract` does not have have a definition in this class,
-    but must have a definition in any non-`abstract` derived class.
+-   A method marked `abstract` does not have a definition in this class, but
+    must have a definition in any non-`abstract` derived class.
 -   A method marked `impl` has a definition in this class, overriding any
     definition in a base class.
 
@@ -2797,7 +2797,7 @@ Carbon code and the other way around. This ability achieves two goals:
 -   Allows sharing a code and library ecosystem with C and C++.
 -   Allows incremental migration to Carbon from C and C++.
 
-Carbon's approach to interopp is most similar to
+Carbon's approach to interop is most similar to
 [Java/Kotlin interop](interoperability/philosophy_and_goals.md#other-interoperability-layers),
 where the two languages are different, but share enough of runtime model that
 data from one side can be used from the other. For example, C++ and Carbon will
diff --git a/docs/design/classes.md b/docs/design/classes.md
index 497da7dd6706..79484cc710f7 100644
--- a/docs/design/classes.md
+++ b/docs/design/classes.md
@@ -177,8 +177,8 @@ strategies that allow operations performed through the pointer to the base type
 work independent of which derived type it actually points to. These strategies
 include:
 
--   Arranging for the the data layout of derived types to start with the data
-    layout of the base type as a prefix.
+-   Arranging for the data layout of derived types to start with the data layout
+    of the base type as a prefix.
 -   Putting a pointer to a table of function pointers, a
     [_vtable_](https://en.wikipedia.org/wiki/Virtual_method_table), as the first
     data member of the object. This allows methods to be
@@ -892,7 +892,7 @@ c.Expand(0.5);
 Assert(Math.Abs(c.Diameter() - 4.0) < 0.001);
 ```
 
--   Methods are called using using the dot `.` member syntax, `c.Diameter()` and
+-   Methods are called using the dot `.` member syntax, `c.Diameter()` and
     `c.Expand(`...`)`.
 -   `Diameter` computes and returns the diameter of the circle without modifying
     the `Circle` instance. This is signified using `[me: Self]` in the method
diff --git a/docs/design/code_and_name_organization/README.md b/docs/design/code_and_name_organization/README.md
index 6930ced3f9f2..bb691790285d 100644
--- a/docs/design/code_and_name_organization/README.md
+++ b/docs/design/code_and_name_organization/README.md
@@ -575,7 +575,7 @@ server for open source packages. Conflicts can also be addressed by renaming one
 of the packages, either at the source, or as a local modification.
 
 We do need to address the case of package names conflicting with other entity
-names. It's possible that a pre-existing entity will conflict with a new import,
+names. It's possible that a preexisting entity will conflict with a new import,
 and that renaming the entity is infeasible to rename due to existing callers.
 Alternately, the entity may be using an idiomatic name that it would contradict
 naming conventions to rename. In either case, this conflict may exist in a
diff --git a/docs/design/generics/details.md b/docs/design/generics/details.md
index 8f3b6cc4c46d..44f2a57eb932 100644
--- a/docs/design/generics/details.md
+++ b/docs/design/generics/details.md
@@ -2812,7 +2812,7 @@ function as an argument to a parameterized type, as in the previous case, and in
 addition the function needs the result to implement a specific interface.
 
 ```
-// Some parametized type.
+// Some parameterized type.
 class Vector(T:! Type) { ... }
 
 // Parameterized type implements interface only for some arguments.
diff --git a/docs/design/generics/overview.md b/docs/design/generics/overview.md
index 2f6810f8bee9..449a6155b344 100644
--- a/docs/design/generics/overview.md
+++ b/docs/design/generics/overview.md
@@ -642,7 +642,7 @@ implement the `Negatable` interface for that type. The interfaces and rewrites
 used for a given operator may be found in the
 [expressions design](/docs/design/expressions/README.md).
 
-As a convenience, there is a shorcut for defining an implementation that
+As a convenience, there is a shortcut for defining an implementation that
 supports any type implicitly convertible to a specified type, using `like`:
 
 ```
diff --git a/docs/project/groups.md b/docs/project/groups.md
index ee05080ab660..85069a03b696 100644
--- a/docs/project/groups.md
+++ b/docs/project/groups.md
@@ -60,5 +60,5 @@ escalating to the [Carbon leads](#carbon-leads). Notably, this team is _not_
 responsible for the _design_ of the language itself, only for its
 implementation.
 
--   [Github team](https://github.com/orgs/carbon-language/teams/implementation-team)
+-   [GitHub team](https://github.com/orgs/carbon-language/teams/implementation-team)
 -   Discord role: implementation-team
diff --git a/docs/project/principles/one_way.md b/docs/project/principles/one_way.md
index 49da7fe135c9..0e8b3d831554 100644
--- a/docs/project/principles/one_way.md
+++ b/docs/project/principles/one_way.md
@@ -55,8 +55,8 @@ A couple examples of this in other languages are:
 
 In Carbon, we will prefer providing only one way to do a given thing. That is,
 given a syntax scenario where multiple design options are available, we will
-tend to provide _one_ option rather than than providing several and letting
-users choose. This echoes Python's principle.
+tend to provide _one_ option rather than providing several and letting users
+choose. This echoes Python's principle.
 
 Minimizing choices serves several goals:
 
diff --git a/docs/project/principles/safety_strategy.md b/docs/project/principles/safety_strategy.md
index 59dc53ea6cd0..b442cb5a942e 100644
--- a/docs/project/principles/safety_strategy.md
+++ b/docs/project/principles/safety_strategy.md
@@ -321,7 +321,7 @@ will adopt a strategy based on three build modes that target key use-cases.
 #### Debug
 
 The debug build mode targets developers who are iterating on code and running
-tests. It will emphasize detection and debugability, especially for safety
+tests. It will emphasize detection and debuggability, especially for safety
 issues.
 
 It needs to perform well enough to be run frequently by developers, but will
@@ -330,7 +330,7 @@ runtime checks for the most common safety issues, but it can make trade-offs
 that improve performance in exchange for less frequent, but still reliable,
 detection. Developers should do most of their testing in this build mode.
 
-The debug build mode will place a premium on the debugability of safety
+The debug build mode will place a premium on the debuggability of safety
 violations. Where safety checks rely on hardening instead of guaranteed safety,
 violations should be detected with a high probability per single occurrence of
 the bug. Detected bugs will be accompanied by a detailed diagnostic report to
diff --git a/docs/project/pull_request_workflow.md b/docs/project/pull_request_workflow.md
index c8ccfae75332..e04788b50738 100644
--- a/docs/project/pull_request_workflow.md
+++ b/docs/project/pull_request_workflow.md
@@ -211,7 +211,7 @@ required):
     # Update your fork (optional).
     git push
 
-    # Merge changes from upstream into your bracnh without disrpting history.
+    # Merge changes from upstream into your branch without disrupting history.
     git checkout feature-basic
     git merge trunk
     # Push to the first PR on your fork.
@@ -219,7 +219,7 @@ required):
     # Synchronize the upstream tracking branch for the first PR.
     git push upstream HEAD:pull-N-feature-basic
 
-    # Merge changes from the the first PR (now including changes from trunk)
+    # Merge changes from the first PR (now including changes from trunk)
     # without disrupting history.
     git checkout next-feature-extension
     git merge feature-basic
diff --git a/docs/project/roadmap.md b/docs/project/roadmap.md
index e94ba1060fed..3f60cf6b71e8 100644
--- a/docs/project/roadmap.md
+++ b/docs/project/roadmap.md
@@ -77,7 +77,7 @@ set of perspectives in the evolution of Carbon as possible.
 
 As a proxy for the amount of participation, we will count the number of active
 participants from each organization in 2022, with the aim that each organization
-is represented by less than 50% of all active participatnts.
+is represented by less than 50% of all active participants.
 
 There are many ways in which someone could be an active participant, and when
 the leads come to reflect on this at the end of the year, we expect this to be a
diff --git a/explorer/ast/impl_binding.h b/explorer/ast/impl_binding.h
index 5031611d0e2d..abeb70787fca 100644
--- a/explorer/ast/impl_binding.h
+++ b/explorer/ast/impl_binding.h
@@ -48,7 +48,7 @@ class ImplBinding : public AstNode {
   // The interface being implemented.
   auto interface() const -> Nonnull<const Value*> { return iface_; }
 
-  // Required for the the ValueNode interface
+  // Required for the ValueNode interface
   auto constant_value() const -> std::optional<Nonnull<const Value*>> {
     return std::nullopt;
   }
diff --git a/explorer/fuzzing/fuzzer_util_test.cpp b/explorer/fuzzing/fuzzer_util_test.cpp
index 86ceb3d6a05c..ddee7c555cd8 100644
--- a/explorer/fuzzing/fuzzer_util_test.cpp
+++ b/explorer/fuzzing/fuzzer_util_test.cpp
@@ -27,7 +27,7 @@ TEST(FuzzerUtilTest, RunFuzzerOnCorpus) {
     std::stringstream contents;
     contents << file.rdbuf();
     // Parsing errors are ignored to make the fuzzer inputs less brittle as the
-    // exlorer code changes. This also matches standard fuzzer behavior.
+    // explorer code changes. This also matches standard fuzzer behavior.
     if (auto carbon_proto = ParseCarbonTextProto(contents.str());
         carbon_proto.ok()) {
       ParseAndExecute(carbon_proto->compilation_unit());
diff --git a/explorer/interpreter/address.h b/explorer/interpreter/address.h
index b42116ce4311..b3d193c12152 100644
--- a/explorer/interpreter/address.h
+++ b/explorer/interpreter/address.h
@@ -16,7 +16,7 @@
 namespace Carbon {
 
 // An AllocationId identifies an _allocation_ produced by a Heap. An allocation
-// is analogous to the C++ notion of a complete object: the the `Value` in an
+// is analogous to the C++ notion of a complete object: the `Value` in an
 // allocation is not a sub-part of any other `Value`.
 class AllocationId {
  public:
diff --git a/explorer/interpreter/impl_scope.cpp b/explorer/interpreter/impl_scope.cpp
index d2ec601e8280..0d3b5dc73842 100644
--- a/explorer/interpreter/impl_scope.cpp
+++ b/explorer/interpreter/impl_scope.cpp
@@ -36,7 +36,7 @@ void ImplScope::Add(Nonnull<const Value*> iface,
       Add(impl.interface, deduced, impl.type, impl_bindings,
           type_checker.MakeConstraintWitnessAccess(impl_expr, i), type_checker);
     }
-    // A paremterized impl declaration doesn't contribute any equality
+    // A parameterized impl declaration doesn't contribute any equality
     // constraints to the scope. Instead, we'll resolve the equality
     // constraints by resolving a witness when needed.
     if (deduced.empty()) {
diff --git a/explorer/testdata/constraint/fail_nontype_self.carbon b/explorer/testdata/constraint/fail_non_type_self.carbon
similarity index 88%
rename from explorer/testdata/constraint/fail_nontype_self.carbon
rename to explorer/testdata/constraint/fail_non_type_self.carbon
index 240a73c109f7..56f8ef358696 100644
--- a/explorer/testdata/constraint/fail_nontype_self.carbon
+++ b/explorer/testdata/constraint/fail_non_type_self.carbon
@@ -12,7 +12,7 @@ package ExplorerTest api;
 
 class X(T:! Type) {}
 
-// CHECK: COMPILATION ERROR: {{.*}}/explorer/testdata/constraint/fail_nontype_self.carbon:[[@LINE+1]]: `.Self` used in type of non-type binding `T`
+// CHECK: COMPILATION ERROR: {{.*}}/explorer/testdata/constraint/fail_non_type_self.carbon:[[@LINE+1]]: `.Self` used in type of non-type binding `T`
 fn F[T:! X(.Self)](x: T) {}
 
 fn Main() -> i32 { return 0; }
diff --git a/migrate_cpp/cpp_refactoring/matcher_test_base.h b/migrate_cpp/cpp_refactoring/matcher_test_base.h
index 8ecbc2312954..3adaf6642241 100644
--- a/migrate_cpp/cpp_refactoring/matcher_test_base.h
+++ b/migrate_cpp/cpp_refactoring/matcher_test_base.h
@@ -23,7 +23,7 @@ class MatcherTestBase : public ::testing::Test {
     matchers.Register(std::make_unique<MatcherFactoryType>());
   }
 
-  // Expects that that the replacements produced by running the finder result in
+  // Expects that the replacements produced by running the finder result in
   // the specified code transformation.
   void ExpectReplacement(llvm::StringRef before, llvm::StringRef after) {
     auto factory =
diff --git a/proposals/p0042.md b/proposals/p0042.md
index 4a898ad6f021..2dbf508baa11 100644
--- a/proposals/p0042.md
+++ b/proposals/p0042.md
@@ -78,7 +78,7 @@ Advantages:
 Disadvantages:
 
 -   Does not meaningfully scale beyond small group of developers with
-    pre-existing shared understanding of desired form of code.
+    preexisting shared understanding of desired form of code.
     -   Relies on relative infrequency of needing code review comments.
     -   Developers largely need to be well aligned and reliably writing code
         others would already approve.
diff --git a/proposals/p0044.md b/proposals/p0044.md
index 7acbb74cbc6a..f0568dc6c130 100644
--- a/proposals/p0044.md
+++ b/proposals/p0044.md
@@ -876,7 +876,7 @@ There are multiple markdown editing tools.
 https://stackedit.io/
 
 StackEdit may look good on the surface, but we may effectively be restricted to
-using it as a WYSYWIG markdown editor, not for collaboration. For that, it's
+using it as a WYSIWYG markdown editor, not for collaboration. For that, it's
 simply one option amongst many, and not necessarily the best.
 
 Advantages:
diff --git a/proposals/p0051.md b/proposals/p0051.md
index 43f6dc8d49fe..4feaa4326f4c 100644
--- a/proposals/p0051.md
+++ b/proposals/p0051.md
@@ -105,8 +105,8 @@ Disadvantages:
 -   While interoperability is critical, the same is true of other goals; this
     isn't enough to determine priority.
 -   There are trade-offs between goals where there is already a consensus that
-    inteoperability will be diminished in favor of other goals, and there aren't
-    as many clear cases in the other direction.
+    interoperability will be diminished in favor of other goals, and there
+    aren't as many clear cases in the other direction.
     -   Taken to extremes, making interoperability and migration a higher
         priority than evolution would suggest that Carbon should start with C++
         and incrementally evolve from that base. We have observed areas where
diff --git a/proposals/p0083.md b/proposals/p0083.md
index 547184dced83..ac99a0c9b265 100644
--- a/proposals/p0083.md
+++ b/proposals/p0083.md
@@ -174,7 +174,7 @@ only to the broad picture painted by the combination of those decisions, and
 that all such decisions need to be revisited by another proposal before we
 consider them to be agreed on. There is a substantial risk of anchoring how we
 think about Carbon -- we’ll just have to do our best to avoid taking this doc as
-a given when evaluating subsequent proposals. Those propopsals must justify a
+a given when evaluating subsequent proposals. Those proposals must justify a
 direction that agrees with this doc as much as one that does not agree with it.
 
 This doc sets the stage for increasingly incremental steps towards a complete
diff --git a/proposals/p0107.md b/proposals/p0107.md
index 9e6539d10d53..4970e7ab69cd 100644
--- a/proposals/p0107.md
+++ b/proposals/p0107.md
@@ -1169,7 +1169,7 @@ Disadvantages:
 -   Loses out on parser benefits of knowing which identifiers are being
     imported.
 -   Increases the risk of adding new features to APIs, as they may immediately
-    get imported by a user and conflict with a pre-existing name, breaking code.
+    get imported by a user and conflict with a preexisting name, breaking code.
 -   As the number of imports increases, it can become difficult to tell which
     import a particular symbol comes from, or how imports are being used.
 -   Arbitrary code inclusion can result in unexpected code execution, a way to
diff --git a/proposals/p0142.md b/proposals/p0142.md
index e163a7d46094..657442f75290 100644
--- a/proposals/p0142.md
+++ b/proposals/p0142.md
@@ -124,12 +124,12 @@ The choice to require NFC is really four choices:
     See also the discussion of [homoglyphs](#homoglyphs) below.
 
 2. Composition: we use a composed normalization form rather than a decomposed
-   normalization form. For example, `ō` is encooded as U+014D (LATIN SMALL
-   LETTER O WITH MACRON) in a composed form and as U+006F (LATIN SMALL LETTER
-   O), U+0304 (COMBINING MACRON) in a decomposed form. The composed form results
-   in smaller representations whenever the two differ, but the decomposed form
-   is a little easier for algorithmic processing (for example, typo correction
-   and homoglyph detection).
+   normalization form. For example, `ō` is encoded as U+014D (LATIN SMALL LETTER
+   O WITH MACRON) in a composed form and as U+006F (LATIN SMALL LETTER O),
+   U+0304 (COMBINING MACRON) in a decomposed form. The composed form results in
+   smaller representations whenever the two differ, but the decomposed form is a
+   little easier for algorithmic processing (for example, typo correction and
+   homoglyph detection).
 
 3. We require source files to be in our chosen form, rather than converting to
    that form as necessary.
diff --git a/proposals/p0157.md b/proposals/p0157.md
index 907b39332eee..99cddeeef2c2 100644
--- a/proposals/p0157.md
+++ b/proposals/p0157.md
@@ -893,7 +893,7 @@ struct Result(Type:$$ T, Type:$$ Error) {
 This approach has several advantages:
 
 -   It's somewhat simpler, because it uses return values instead of
-    continution-passing.
+    continuation-passing.
 -   It will be easier for the compiler to reason about, because of that
     simplicity and the somewhat narrower API surface. This may lead to better
     compiler performance, and better generated code.
diff --git a/proposals/p0199.md b/proposals/p0199.md
index 17a6baa6d065..d669db8688bd 100644
--- a/proposals/p0199.md
+++ b/proposals/p0199.md
@@ -655,7 +655,7 @@ raw strings. There are several reasons to prefer Swift-style raw strings:
 -   Swift raw strings are not a distinct language feature; rather, they are a
     generalization of non-raw strings -- non-raw strings are simply the case
     where the number of `#` characters in the delimiters and escape sequence
-    intorducer is zero.
+    introducer is zero.
 -   Permitting escape sequences even in raw strings means that there is no loss
     of functionality when using a raw string, and code changes under maintenance
     that would require use of a facility only available by way of an escape
diff --git a/proposals/p0285.md b/proposals/p0285.md
index 44dcd7dbb5ef..7451db4fa45e 100644
--- a/proposals/p0285.md
+++ b/proposals/p0285.md
@@ -109,7 +109,7 @@ are no braces, only one statement is allowed.
 ```bison
 statement:
   "if" '(' expression ')' statement optional_else
-| /* pre-existing statements elided */
+| /* preexisting statements elided */
 ;
 
 optional_else:
diff --git a/proposals/p0339.md b/proposals/p0339.md
index b8247a064e94..dbe1bd84d754 100644
--- a/proposals/p0339.md
+++ b/proposals/p0339.md
@@ -173,7 +173,7 @@ Example bison syntax for executable semantics is:
 ```bison
 statement:
   "var" expression identifier optional_assignment;
-| /* pre-existing statements elided */
+| /* preexisting statements elided */
 ;
 
 optional_assignment:
diff --git a/proposals/p0340.md b/proposals/p0340.md
index b68de7583ad9..1e7f54fa9d9f 100644
--- a/proposals/p0340.md
+++ b/proposals/p0340.md
@@ -150,7 +150,7 @@ statement:
   WHILE '(' expression ')' statement
 | CONTINUE ';'
 | BREAK ';'
-| /* pre-existing statements elided */
+| /* preexisting statements elided */
 ;
 ```
 
diff --git a/proposals/p0353.md b/proposals/p0353.md
index 1bc9bebf0c14..b5b5ed1b9a3e 100644
--- a/proposals/p0353.md
+++ b/proposals/p0353.md
@@ -163,7 +163,7 @@ still establish critical things to support:
 
 statement:
   FOR "(" pattern ":" expression ")" statement
-| /* pre-existing statements elided */
+| /* preexisting statements elided */
 ;
 ```
 
diff --git a/proposals/p0553.md b/proposals/p0553.md
index 0dc5a9a5de80..b74921f38680 100644
--- a/proposals/p0553.md
+++ b/proposals/p0553.md
@@ -141,8 +141,8 @@ Advantage:
 
 Disadvantages:
 
--   Less explicit that the the methods of this impl definition are not
-    contributing to unqualified API of the type.
+-   Less explicit that the methods of this impl definition are not contributing
+    to unqualified API of the type.
 -   This kind of implementation is naturally referred to as "external",
     especially when contrasting with "inline impl".
 
diff --git a/proposals/p0676.md b/proposals/p0676.md
index eb3387ab3cab..3ec3c18aba2a 100644
--- a/proposals/p0676.md
+++ b/proposals/p0676.md
@@ -176,7 +176,7 @@ var to: Vector(i64) = CastAVector(from, i64);
 -   There was no reason to prefer this over the previous option, since `<`...`>`
     is more associated with generics than `[`...`]`.
 
-Other different spellings of the `:!` position that came up during brainstroming
+Other different spellings of the `:!` position that came up during brainstorming
 but were not found to be compelling included:
 
 -   `<id>: Type`
diff --git a/proposals/p0680.md b/proposals/p0680.md
index 116c14f51680..838179f3b08a 100644
--- a/proposals/p0680.md
+++ b/proposals/p0680.md
@@ -67,7 +67,8 @@ these operators:
 Perl, Ruby, and Raku permit both syntaxes, giving the punctuation forms higher
 precedence and the keyword forms lower precedence. Both forms short-circuit.
 Raku also provides `andthen` and `orelse`, but these differ from `and` and `or`
-in what value is produced on short-ciruiting, not in whether they short-ciruit.
+in what value is produced on short-circuiting, not in whether they
+short-circuit.
 
 Zig provides `and`, `or`, and `!`.
 
diff --git a/proposals/p0702.md b/proposals/p0702.md
index e6ca7b1e873f..6227c6be7cbf 100644
--- a/proposals/p0702.md
+++ b/proposals/p0702.md
@@ -76,7 +76,7 @@ For equality operators, there is some divergence but still a very strong trend:
 -   Some languages, such as Pascal and BASIC, use `<>` for inequality
     comparison. Python 2 permits this as a synonym for `!=`.
 -   Perl uses `eq` and `ne` for string comparisons; some shells and UNIX `test`
-    use `-eq` and `-ne` for for integer comparisons.
+    use `-eq` and `-ne` for integer comparisons.
 
 Some languages support multiple different kinds of equality comparison, such as
 both a value comparison (typically `==`) and an object identity comparison
@@ -448,7 +448,7 @@ Disadvantages:
     changing the semantics of the operator expression as we can no longer move
     from the operand.
 -   Both short-circuiting behavior and non-short-circuiting behavior will be
-    surprising and unintuitive to some. The short-circiuting option will
+    surprising and unintuitive to some. The short-circuiting option will
     introduce control flow without a keyword to announce it, which goes against
     our design decision to use a keyword for `and` and `or` to announce the
     control flow. The non-short-circuiting option will evaluate subexpressions
diff --git a/proposals/p0722.md b/proposals/p0722.md
index 422967603739..d3bad6970e39 100644
--- a/proposals/p0722.md
+++ b/proposals/p0722.md
@@ -80,7 +80,7 @@ A wide variety of alternatives were considered:
 -   Putting the receiver pattern in a separate set of brackets. This could be an
     additional set of parens `(`...`)` before the explicit parameter list. Or
     the deduced parameters could be put in angle brackets `<`...`>` and the
-    receiver in square brackes `[`...`]`.
+    receiver in square brackets `[`...`]`.
 
 Examples:
 
@@ -168,7 +168,7 @@ concerns, however, that this parameter did not act like deduced parameters.
 ##### Receiver parameter is named `me`
 
 Having the receiver name be fixed is helpful for consistency. This benefits
-readers, and simplfies copying or moving code between functions. A fixed
+readers, and simplifies copying or moving code between functions. A fixed
 receiver name also allows us to identify the receiver pattern in the function
 declaration, and identify it as a method instead of an ordinary function
 associated with the type, like
diff --git a/proposals/p0777.md b/proposals/p0777.md
index 4628df3e592d..c3c4d664ce38 100644
--- a/proposals/p0777.md
+++ b/proposals/p0777.md
@@ -481,7 +481,7 @@ Issue [#652](https://github.com/carbon-language/carbon-lang/issues/652)
 considered many variations on ways to have two different types for values
 depending on whether they represented a value with an exact type, or a value
 that could be a derived type. We ultimately decided that asking users to use
-both types would be too much congnitive overhead, and would be a usability
+both types would be too much cognitive overhead, and would be a usability
 regression from C++.
 
 ### Separate "exact" and "or derived" variations on pointers
diff --git a/proposals/p0875.md b/proposals/p0875.md
index cd0c48aa91e4..238000371879 100644
--- a/proposals/p0875.md
+++ b/proposals/p0875.md
@@ -483,7 +483,7 @@ separate declaration from definition may create friction, due to the familiarity
 of that feature and having their thinking about code layout shaped around it.
 Given that Carbon aims to be familiar to those coming from C++, an absence of
 forward declarations will work against that goal to some extent, although
-emiprical evidence suggests that the extent to which this is an issue varies
+empirical evidence suggests that the extent to which this is an issue varies
 widely between existing C++ developers.
 
 _Efficient and simple compilation:_ This approach leads to a simpler compilation
@@ -579,7 +579,7 @@ they need only consider prior code, and there is no possibility that a later
 source utterance could change the meaning of the code they're reading. However,
 it is rare to read code top-down, so the effect of this advantage may be modest.
 
-This advantage leads to a significant disadvantange: the behaviour of an entity
+This advantage leads to a significant disadvantage: the behaviour of an entity
 can be different at different places within a source file. For example, a type
 can be incomplete in one place and complete in another, or can fail to implement
 an interface when inspected early and then found to implement that interface
diff --git a/proposals/p1083.md b/proposals/p1083.md
index 9e035b55ab16..3e8dd5434696 100644
--- a/proposals/p1083.md
+++ b/proposals/p1083.md
@@ -174,7 +174,7 @@ focus on the rationale and alternatives.
         possible value, in order to make it simple to factor out subexpressions.
 -   [Code that is easy to read, understand, and write](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write)
     -   Using the same operators as other languages, with largely the same
-        semantics as C++, should aid readability and writeability especially for
+        semantics as C++, should aid readability and writability especially for
         those with less Carbon-specific knowledge.
     -   Performing built-in arithmetic in the larger operand type and refusing
         cases where a lossy conversion would be performed in C++ reduces the
diff --git a/proposals/p1084.md b/proposals/p1084.md
index 986aeb76790c..c1922a51e719 100644
--- a/proposals/p1084.md
+++ b/proposals/p1084.md
@@ -166,7 +166,7 @@ interface EdgeInterface {
 // terms of `NodeBootstrap`, adding in constraints that
 // couldn't be written until `EdgeInterface` was defined.
 constraint NodeInterface {
-  extends NodeBootsrap where .EdgeType.NodeType == Self;
+  extends NodeBootstrap where .EdgeType.NodeType == Self;
 }
 ```
 
diff --git a/proposals/p1154.md b/proposals/p1154.md
index c059707e1ff6..3c32008a4cdf 100644
--- a/proposals/p1154.md
+++ b/proposals/p1154.md
@@ -133,7 +133,7 @@ destructor can acquire locks before any unsynchronized writes occur.
 We didn't decide to include this approach in this proposal, since we felt like
 it would likely be too burdensome to prevent calling member functions from a
 destructor unless the developer did some extra work to mark all functions it
-transtively calls. We would consider this as a potential future extension. As
+transitively calls. We would consider this as a potential future extension. As
 noted in the design, this could be achieved by using the `partial` type.
 
 This was considered in the open discussions on
diff --git a/proposals/p1191.md b/proposals/p1191.md
index 62a23f5e051f..1820579e3224 100644
--- a/proposals/p1191.md
+++ b/proposals/p1191.md
@@ -38,7 +38,7 @@ Carbon needs operations for working with bit representations of values.
 ## Background
 
 C++ provides four bitwise operations for Boolean algebra: complement (`~`), and
-(`&`), or (`|`), and xor (`^`). These are all useful in bit-maipulation code
+(`&`), or (`|`), and xor (`^`). These are all useful in bit-manipulation code
 (although `^` is used substantially less than the others). In addition, C++
 provides two bit-shift operators `<<` and `>>` that can perform three different
 operations: left shift, arithmetic right shift, and logical right shift. The
@@ -137,10 +137,10 @@ See changes to the design, and in particular
         be easy for programmers to accommodate, especially given that Rust's
         choice to replace `~` with `!` does not seem to be a source of sustained
         complaints.
-    -   The extensiblity support reflects the full scope of operator overloading
-        in C++, permitting separate overloading of each of the bitwise operators
-        with custom return types. This should allow smooth interoperability with
-        C++ overloaded operators.
+    -   The extensibility support reflects the full scope of operator
+        overloading in C++, permitting separate overloading of each of the
+        bitwise operators with custom return types. This should allow smooth
+        interoperability with C++ overloaded operators.
 
 ## Alternatives considered
 
diff --git a/proposals/p1270.md b/proposals/p1270.md
index f3c36c773de6..53a879598f50 100644
--- a/proposals/p1270.md
+++ b/proposals/p1270.md
@@ -60,7 +60,7 @@ See the pull request for the detailed change.
         project remains transparent and clear.
 -   [Software and language evolution](/docs/project/goals.md#software-and-language-evolution)
     -   Understanding the _motivations_ of the Carbon project will be important
-        for future language evolution efforst.
+        for future language evolution efforts.
 
 ## Alternatives considered
 
diff --git a/proposals/p1344.md b/proposals/p1344.md
index 74193f1f8511..ee76039ce70d 100644
--- a/proposals/p1344.md
+++ b/proposals/p1344.md
@@ -139,9 +139,8 @@ save, we suggest the following process:
 
 3.  Update any clones to use these archived remotes to avoid accidentally trying
     to interact with the new repository. Example commands assuming the remote
-    `origin` points to your fork and and `upstream` points to the main
-    repository. You may also need to adjust from the SSH-style URLs to HTTPS
-    ones to match:
+    `origin` points to your fork and `upstream` points to the main repository.
+    You may also need to adjust from the SSH-style URLs to HTTPS ones to match:
 
     ```
     git remote set-url upstream git@github.com:carbon-language/archived-carbon-lang.git git@github.com:carbon-language/carbon-lang.git
diff --git a/proposals/p1367.md b/proposals/p1367.md
index ff74f6a25ba6..b4d6143c24b8 100644
--- a/proposals/p1367.md
+++ b/proposals/p1367.md
@@ -154,7 +154,7 @@ Advantages:
     [stacked PR](/docs/project/pull_request_workflow.md#stacking-dependent-pull-requests)
     advice.
 
-Diadvantages:
+Disadvantages:
 
 -   Retains team-specific bottlenecks: if none of a directory's owners are
     available, other contributors cannot step in.
diff --git a/third_party/examples/re2/re2.carbon b/third_party/examples/re2/re2.carbon
index 244654301457..54094ba5ce8a 100644
--- a/third_party/examples/re2/re2.carbon
+++ b/third_party/examples/re2/re2.carbon
@@ -608,7 +608,7 @@ class RE2 {
   // Replace(). E.g. if rewrite == "foo \\2,\\1", returns 2.
   fn MaxSubmatch(rewrite: StringPiece) -> i32;
 
-  // Append the "rewrite" string, with backslash subsitutions from "vec",
+  // Append the "rewrite" string, with backslash substitutions from "vec",
   // to string "out".
   // Returns true on success.  This method can fail because of a malformed
   // rewrite string.  CheckRewriteString guarantees that the rewrite will
diff --git a/third_party/examples/woff2/carbon/src/font.carbon b/third_party/examples/woff2/carbon/src/font.carbon
index ac7df3ac7c68..76f129a908cf 100644
--- a/third_party/examples/woff2/carbon/src/font.carbon
+++ b/third_party/examples/woff2/carbon/src/font.carbon
@@ -51,7 +51,7 @@ struct Font {
   [[nodiscard]] fn FindTable(tag: uint32_t) const -> const Table*;
 };
 
-// Accomodates both singular (OTF, TTF) and collection (TTC) fonts
+// Accommodates both singular (OTF, TTF) and collection (TTC) fonts
 struct FontCollection {
   uint32_t flavor;
   uint32_t header_version;
diff --git a/third_party/examples/woff2/carbon/src/normalize.carbon b/third_party/examples/woff2/carbon/src/normalize.carbon
index df151305cb0b..d153ec4b1ee4 100644
--- a/third_party/examples/woff2/carbon/src/normalize.carbon
+++ b/third_party/examples/woff2/carbon/src/normalize.carbon
@@ -27,7 +27,7 @@ fn FixChecksums(font: Font*) -> bool;
 
 // Parses each of the glyphs in the font and writes them again to the glyf
 // table in normalized form, as defined by the StoreGlyph() function. Changes
-// the loca table accordigly.
+// the loca table accordingly.
 fn NormalizeGlyphs(font: Font*) -> bool;
 
 // Performs all of the normalization steps above.
diff --git a/toolchain/parser/parse_tree_test.cpp b/toolchain/parser/parse_tree_test.cpp
index 8c9a9fa304e7..2fd008fd7681 100644
--- a/toolchain/parser/parse_tree_test.cpp
+++ b/toolchain/parser/parse_tree_test.cpp
@@ -366,7 +366,7 @@ TEST_F(ParseTreeTest, BasicFunctionDefinition) {
                          MatchFileEnd()}));
 }
 
-TEST_F(ParseTreeTest, FunctionDefinitionWithIdenifierInStatements) {
+TEST_F(ParseTreeTest, FunctionDefinitionWithIdentifierInStatements) {
   TokenizedBuffer tokens = GetTokenizedBuffer(
       "fn F() {\n"
       "  bar\n"
diff --git a/toolchain/parser/parser_impl.cpp b/toolchain/parser/parser_impl.cpp
index 5b1ca711e601..06e454523a40 100644
--- a/toolchain/parser/parser_impl.cpp
+++ b/toolchain/parser/parser_impl.cpp
@@ -978,7 +978,7 @@ auto ParseTree::Parser::ParseOperatorExpression(
     if (PrecedenceGroup::GetPriority(lhs_precedence, operator_precedence) !=
         OperatorPriority::LeftFirst) {
       // Either the LHS operator and this operator are ambiguous, or the
-      // LHS operaor is a unary operator that can't be nested within
+      // LHS operator is a unary operator that can't be nested within
       // this operator. Either way, parentheses are required.
       emitter_.Emit(*position_, OperatorRequiresParentheses);
       lhs = llvm::None;
diff --git a/toolchain/parser/precedence.cpp b/toolchain/parser/precedence.cpp
index 26a8706b0853..31c3d633e8bc 100644
--- a/toolchain/parser/precedence.cpp
+++ b/toolchain/parser/precedence.cpp
@@ -259,7 +259,7 @@ auto PrecedenceGroup::ForTrailing(TokenKind kind, bool infix)
     case TokenKind::LessEqualGreater():
       return Trailing{.level = Relational, .is_binary = true};
 
-    // Addative operators.
+    // Additive operators.
     case TokenKind::Plus():
     case TokenKind::Minus():
       return Trailing{.level = Additive, .is_binary = true};