diff --git a/docs/content/1.getting-started/4.bridge.md b/docs/content/1.getting-started/4.bridge.md
index e7f5b1e20..671d718d7 100644
--- a/docs/content/1.getting-started/4.bridge.md
+++ b/docs/content/1.getting-started/4.bridge.md
@@ -136,7 +136,7 @@ You may also need to add `@vue/runtime-dom` as a devDependency if you are strugg
 ::
 ::alert
 Keep in mind that all options extended from `./.nuxt/tsconfig.json` will be overwritten by the options defined in your `tsconfig.json`.
-Overwriting options such as `"compilerOptions.paths"` with your own configuration will lead Typescript to not factor in the module resolutions from `./.nuxt/tsconfig.json`. This can lead to module resolutions such as `#imports` not being recognized.
+Overwriting options such as `"compilerOptions.paths"` with your own configuration will lead TypeScript to not factor in the module resolutions from `./.nuxt/tsconfig.json`. This can lead to module resolutions such as `#imports` not being recognized.
 
 In case you need to extend options provided by `./.nuxt/tsconfig.json` further, you can use the `alias` property withing your `nuxt.config`. `nuxi` will pick them up and extend `./.nuxt/tsconfig.json` accordingly.
 ::
diff --git a/docs/content/2.concepts/2.vuejs-development.md b/docs/content/2.concepts/2.vuejs-development.md
index 73686ccc4..9f5b08575 100644
--- a/docs/content/2.concepts/2.vuejs-development.md
+++ b/docs/content/2.concepts/2.vuejs-development.md
@@ -52,7 +52,7 @@ Nuxt 3 is based on Vue 3. The new Vue major version introduces several changes t
 
 - Better performances
 - Composition API
-- Typescript support
+- TypeScript support
 
 ### Faster rendering
 
@@ -103,10 +103,10 @@ The goal of Nuxt 3 is to provide a great developer experience around the composi
 - Use auto-imported [Reactivity functions](https://vuejs.org/api/reactivity-core.html) from Vue and Nuxt 3 [built-in composables](/docs/usage/data-fetching).
 - Write your own auto-imported reusable functions in the `composables/` directory.
 
-### Typescript support
+### TypeScript support
 
-Both Vue 3 and Nuxt 3 are written in Typescript. A fully typed codebase prevents mistakes and documents APIs usage. This doesn’t mean that you have to write your application in Typescript to take advantage of it. With Nuxt 3, you can opt-in by renaming your file from `.js` to `.ts` , or add `<script lang="ts">` in a component.
+Both Vue 3 and Nuxt 3 are written in TypeScript. A fully typed codebase prevents mistakes and documents APIs usage. This doesn’t mean that you have to write your application in TypeScript to take advantage of it. With Nuxt 3, you can opt-in by renaming your file from `.js` to `.ts` , or add `<script lang="ts">` in a component.
 
 ::alert{type="info"}
-🔎 [Read the details about Typescript in Nuxt 3](/concepts/typescript)
+🔎 [Read the details about TypeScript in Nuxt 3](/concepts/typescript)
 ::
diff --git a/docs/content/2.concepts/3.rendering.md b/docs/content/2.concepts/3.rendering.md
index 5d2e656c5..d6e371b7b 100644
--- a/docs/content/2.concepts/3.rendering.md
+++ b/docs/content/2.concepts/3.rendering.md
@@ -1,10 +1,10 @@
 # Rendering Modes
 
-Both Browser and Server can interpret Javascript code to render Vue.js components into HTML elements. This step is called **rendering**. Nuxt supports both **client-side** and **universal** rendering. The two approaches have pros and cons that we will cover in this section.
+Both Browser and Server can interpret JavaScript code to render Vue.js components into HTML elements. This step is called **rendering**. Nuxt supports both **client-side** and **universal** rendering. The two approaches have pros and cons that we will cover in this section.
 
 ## Client-side only rendering
 
-Out of the box, a traditional Vue.js application is rendered in the browser (or **client**). Then, Vue.js generates HTML elements after the browser downloads and parses all the Javascript code containing the instructions to create the current interface.
+Out of the box, a traditional Vue.js application is rendered in the browser (or **client**). Then, Vue.js generates HTML elements after the browser downloads and parses all the JavaScript code containing the instructions to create the current interface.
 
 ![Users have to wait for the javascript to be downloaded, parsed and executed before seeing the page's content](/img/concepts/rendering/light/csr.svg){.dark:hidden}
 ![Users have to wait for the javascript to be downloaded, parsed and executed before seeing the page's content](/img/concepts/rendering/dark/csr.svg){.light:hidden}
@@ -14,7 +14,7 @@ While this technique allows building complex and dynamic UIs with smooth page tr
 ### Pros
 
 - **Development speed**: When working entirely on the client-side, we don't have to worry about the server compatibility of the code, for example, by using browser-only APIs like the `window` object.
-- **Cheaper:** Running a server adds a cost of infrastructure as you would need to run on a platform that supports Javascript. We can host Client-only applications on any static server with HTML, CSS, and Javascript files.
+- **Cheaper:** Running a server adds a cost of infrastructure as you would need to run on a platform that supports JavaScript. We can host Client-only applications on any static server with HTML, CSS, and JavaScript files.
 - **Offline:** Because code entirely runs in the browser, it can nicely keep working while the internet is unavailable.
 
 ### Cons
@@ -28,7 +28,7 @@ Client-side rendering is a good choice for heavily interactive **web application
 
 ## Universal Rendering
 
-When the browser requests a URL with universal (client-side + server-side) rendering enabled, the server returns a fully rendered HTML page to the browser. Whether the page has been generated in advance and cached or is rendered on the fly, at some point, Nuxt has run the Javascript (Vue.js) code in a server environment, producing an HTML document. Users immediately get the content of our application, contrary to client-side rendering. This step is similar to traditional **server-side rendering** performed by PHP or Ruby applications.
+When the browser requests a URL with universal (client-side + server-side) rendering enabled, the server returns a fully rendered HTML page to the browser. Whether the page has been generated in advance and cached or is rendered on the fly, at some point, Nuxt has run the JavaScript (Vue.js) code in a server environment, producing an HTML document. Users immediately get the content of our application, contrary to client-side rendering. This step is similar to traditional **server-side rendering** performed by PHP or Ruby applications.
 
 To not lose the benefits of the client-side rendering method, such as dynamic interfaces and pages transitions, the Client loads the javascript code that runs on the Server in the background once the HTML document has been downloaded. It is interpreted again by the browser (hence **Universal rendering**) and Vue.js takes control of the document and enables interactivity.
 
@@ -41,7 +41,7 @@ Universal rendering allows a Nuxt application to provide quick page load times w
 
 ### Pros
 
-- **Performance**: Users can get immediate access to the page's content because browsers can display static content much faster than Javascript-generated one. At the same time, Nuxt preserves the interactivity of a web application when the hydration process happens.
+- **Performance**: Users can get immediate access to the page's content because browsers can display static content much faster than JavaScript-generated one. At the same time, Nuxt preserves the interactivity of a web application when the hydration process happens.
 - **Search Engine Optimization**: Universal rendering delivers the entire HTML content of the page to the browser as a classic server application. Web crawlers can directly index the page's content, which makes Universal rendering a great choice for any content that you want to index quickly.
 
 ### Cons
diff --git a/docs/content/2.concepts/6.typescript.md b/docs/content/2.concepts/6.typescript.md
index 4f1b408a7..ed3edac51 100644
--- a/docs/content/2.concepts/6.typescript.md
+++ b/docs/content/2.concepts/6.typescript.md
@@ -31,7 +31,7 @@ Nitro also [auto-generates types](/concepts/server-engine#typed-api-routes) for
 ::
 ::alert
 Keep in mind that all options extended from `./.nuxt/tsconfig.json` will be overwritten by the options defined in your `tsconfig.json`.
-Overwriting options such as `"compilerOptions.paths"` with your own configuration will lead Typescript to not factor in the module resolutions from `./.nuxt/tsconfig.json`. This can lead to module resolutions such as `#imports` not being recognized.
+Overwriting options such as `"compilerOptions.paths"` with your own configuration will lead TypeScript to not factor in the module resolutions from `./.nuxt/tsconfig.json`. This can lead to module resolutions such as `#imports` not being recognized.
 
 In case you need to extend options provided by `./.nuxt/tsconfig.json` further, you can use the `alias` property within your `nuxt.config`. `nuxi` will pick them up and extend `./.nuxt/tsconfig.json` accordingly.
 ::
diff --git a/docs/content/3.docs/8.deployment/2.cloudflare.md b/docs/content/3.docs/8.deployment/2.cloudflare.md
index 65f329f4d..c2f36acde 100644
--- a/docs/content/3.docs/8.deployment/2.cloudflare.md
+++ b/docs/content/3.docs/8.deployment/2.cloudflare.md
@@ -72,7 +72,7 @@ Publish:
 wrangler publish
 ```
 
-## Deploy within CI/CD using Github Actions
+## Deploy within CI/CD using GitHub Actions
 
 Create a token according to [the wrangler action docs](https://github.com/marketplace/actions/deploy-to-cloudflare-workers-with-wrangler#authentication) and set `CF_API_TOKEN` in your repository config on GitHub.
 
diff --git a/docs/content/3.docs/9.advanced/2.modules.md b/docs/content/3.docs/9.advanced/2.modules.md
index 912bb2c0c..1800bab0a 100644
--- a/docs/content/3.docs/9.advanced/2.modules.md
+++ b/docs/content/3.docs/9.advanced/2.modules.md
@@ -19,7 +19,7 @@ Starter template and module starter is a standard path of creating a Nuxt module
 
 **Next steps:**
 
-- Open `my-module` in IDE of your choice (VSCode is recommended)
+- Open `my-module` in IDE of your choice (Visual Studio Code is recommended)
 - Install dependencies using the package manager of your choice (Yarn is recommended)
 - Ensure local files are generated using `npm run dev:prepare`
 - Start playground using `npm run dev`
@@ -106,7 +106,7 @@ Result of `defineNuxtModule` is a wrapper function with `(inlineOptions, nuxt)`
 - Automatically register Nuxt hooks
 - Automatically check for compatibility issues based on module meta
 - Expose `getOptions` and `getMeta` for internal usage of Nuxt
-- Ensuring backward and upward compatibility as long as the module is using `defineNuxtmodule` from the latest version of `@nuxt/kit`
+- Ensuring backward and upward compatibility as long as the module is using `defineNuxtModule` from the latest version of `@nuxt/kit`
 - Integration with module builder tooling
 
 ## Best practices
@@ -125,7 +125,7 @@ Nuxt Modules should provide an explicit prefix for any exposed configuration, pl
 
 Ideally you should prefix them with your module name (If your module is called `nuxt-foo`, expose `<FooButton>` and `useFooBar()` and **not** `<Foo>` and `useBar()`)
 
-### Be Typescript Friendly
+### Be TypeScript Friendly
 
 Nuxt 3, has first-class typescript integration for the best developer experience.
 
diff --git a/docs/content/index.md b/docs/content/index.md
index 88db43057..1cd57373a 100644
--- a/docs/content/index.md
+++ b/docs/content/index.md
@@ -96,7 +96,7 @@ Nuxt 3 has been re-architected with a smaller core and optimized for faster perf
   ::section-content-item
   ---
   title: Nuxt Kit
-  description: 'Brand new module development with Typescript and cross-version compatibility.'
+  description: 'Brand new module development with TypeScript and cross-version compatibility.'
   image: IconKit
   imageClass: w-10 h-10
   ---