docs: fix grammatical errors and improve clarity (#838)

afsuyadi · web-flow · commit a04b483f8f2f · 2026-03-19T19:53:14.000+09:00
* fix typo

* fix grammatical error

* add important punctuations between sentences

* improve passive sentence

* add "the" to refer to specific entry point

* fix compound words

* fix phrasal verbs

* fix official naming for Node.js, JavaScript, TypeScript and remove unnecessary line-spacing between words in a sentence.

* fix punctuation between sentences

* fix grammatical error

* fix official naming for HTML

* fix parallel structure in sentences and remove unnecessary line-spacing between words

* fix subject-verb agreement

* improve instruction

* replace with a better conjunction

* add punctuation between sentences

* add punctuation, fix official naming for CSS

* fix official naming for CSS

* improve sentence clarity
diff --git a/docs/api/context.md b/docs/api/context.md
@@ -45,7 +45,7 @@ const app = new Hono()
 app.get('/', (c) => {
   // Set headers
   c.header('X-Message', 'My custom message')
-  return c.text('HellO!')
+  return c.text('Hello!')
 })
 ```
 
@@ -96,7 +96,7 @@ new Response('Thank you for coming', {
 
 ## text()
 
-Render text as `Content-Type:text/plain`.
+Render text as `Content-Type: text/plain`.
 
 ```ts twoslash
 import { Hono } from 'hono'
@@ -109,7 +109,7 @@ app.get('/say', (c) => {
 
 ## json()
 
-Render JSON as `Content-Type:application/json`.
+Render JSON as `Content-Type: application/json`.
 
 ```ts twoslash
 import { Hono } from 'hono'
@@ -122,7 +122,7 @@ app.get('/api', (c) => {
 
 ## html()
 
-Render HTML as `Content-Type:text/html`.
+Render HTML as `Content-Type: text/html`.
 
 ```ts twoslash
 import { Hono } from 'hono'
diff --git a/docs/api/exception.md b/docs/api/exception.md
@@ -8,7 +8,7 @@ You can throw your own HTTPExceptions by specifying a status code, and either a
 
 ### Custom Message
 
-For basic `text` responses, just set a the error `message`.
+For basic `text` responses, just set the error `message`.
 
 ```ts twoslash
 import { HTTPException } from 'hono/http-exception'
diff --git a/docs/api/hono.md b/docs/api/hono.md
@@ -86,7 +86,7 @@ addEventListener('fetch', (event: FetchEventLike): void => {
 
 ## fetch()
 
-`app.fetch` will be entry point of your application.
+`app.fetch` will be the entry point of your application.
 
 For Cloudflare Workers, you can use the following:
 
diff --git a/docs/api/request.md b/docs/api/request.md
@@ -140,7 +140,7 @@ body['foo[]']
 
 ### Multiple files or fields with same name
 
-If you have a input field that allows multiple `<input type="file" multiple />` or multiple checkboxes with the same name `<input type="checkbox" name="favorites" value="Hono"/>`.
+If you have an input field that allows multiple `<input type="file" multiple />` or multiple checkboxes with the same name `<input type="checkbox" name="favorites" value="Hono"/>`.
 
 ```ts twoslash
 import { Context } from 'hono'
diff --git a/docs/concepts/routers.md b/docs/concepts/routers.md
@@ -8,7 +8,7 @@ Hono has five routers.
 
 **RegExpRouter** is the fastest router in the JavaScript world.
 
-Although this is called "RegExp" it is not an Express-like implementation using [path-to-regexp](https://github.com/pillarjs/path-to-regexp).
+Although this is called "RegExp", it is not an Express-like implementation using [path-to-regexp](https://github.com/pillarjs/path-to-regexp).
 They are using linear loops.
 Therefore, regular expression matching will be performed for all routes and the performance will be degraded as you have more routes.
 
@@ -53,7 +53,7 @@ RegExpRouter is fast, but the route registration phase can be slightly slow.
 So, it's not suitable for an environment that initializes with every request.
 
 **LinearRouter** is optimized for "one shot" situations.
-Route registration is significantly faster than with RegExpRouter because it adds the route without compiling strings, using a linear approach.
+Route registration is significantly faster than RegExpRouter because it adds the route without compiling strings, using a linear approach.
 
 The following is one of the benchmark results, which includes the route registration phase.
 
diff --git a/docs/concepts/stacks.md b/docs/concepts/stacks.md
@@ -1,8 +1,7 @@
 # Hono Stacks
 
 Hono makes easy things easy and hard things easy.
-It is suitable for not just only returning JSON.
-But it's also great for building the full-stack application including REST API servers and the client.
+It is suitable for not just only returning JSON, but it's also great for building the full-stack application including REST API servers and the client.
 
 ## RPC
 
@@ -94,7 +93,7 @@ export type AppType = typeof route
 
 ## Client
 
-Next. The client-side implementation.
+Next, The client-side implementation.
 Create a client object by passing the `AppType` type to `hc` as generics.
 Then, magically, completion works and the endpoint path and request type are suggested.
 
diff --git a/docs/concepts/web-standard.md b/docs/concepts/web-standard.md
@@ -4,7 +4,7 @@ Hono uses only **Web Standards** like Fetch.
 They were originally used in the `fetch` function and consist of basic objects that handle HTTP requests and responses.
 In addition to `Requests` and `Responses`, there are `URL`, `URLSearchParam`, `Headers` and others.
 
-Cloudflare Workers, Deno, and Bun also build upon Web Standards.
+Cloudflare Workers, Deno, and Bun also are built upon Web Standards.
 For example, a server that returns "Hello World" could be written as below. This could run on Cloudflare Workers and Bun.
 
 ```ts twoslash
diff --git a/docs/getting-started/aws-lambda.md b/docs/getting-started/aws-lambda.md
@@ -9,7 +9,7 @@ Hono works on AWS Lambda with the Node.js 18+ environment.
 
 When creating the application on AWS Lambda,
 [CDK](https://docs.aws.amazon.com/cdk/v2/guide/home.html)
-is useful to setup the functions such as IAM Role, API Gateway, and others.
+is useful to set up the functions such as IAM Role, API Gateway, and others.
 
 Initialize your project with the `cdk` CLI.
 
diff --git a/docs/getting-started/azure-functions.md b/docs/getting-started/azure-functions.md
@@ -2,7 +2,7 @@
 
 [Azure Functions](https://azure.microsoft.com/en-us/products/functions) is a serverless platform from Microsoft Azure. You can run your code in response to events, and it automatically manages the underlying compute resources for you.
 
-Hono was not designed for Azure Functions at first. But with [Azure Functions Adapter](https://github.com/Marplex/hono-azurefunc-adapter) it can run on it as well.
+Hono was not designed for Azure Functions at first, but with [Azure Functions Adapter](https://github.com/Marplex/hono-azurefunc-adapter), it can run on it as well.
 
 It works with Azure Functions **V4** running on Node.js 18 or above.
 
diff --git a/docs/getting-started/bun.md b/docs/getting-started/bun.md
@@ -1,6 +1,6 @@
 # Bun
 
-[Bun](https://bun.com) is another JavaScript runtime. It's not Node.js or Deno. Bun includes a trans compiler, we can write the code with TypeScript.
+[Bun](https://bun.com) is another JavaScript runtime. It's not Node.js or Deno. Bun includes a transcompiler, we can write the code with TypeScript.
 Hono also works on Bun.
 
 ## 1. Install Bun
@@ -90,7 +90,7 @@ export default { // [!code ++]
 
 ## Serve static files
 
-To serve static files, use `serveStatic` imported from `hono/bun`.
+To serve static files, use `serveStatic` which is imported from `hono/bun`.
 
 ```ts
 import { serveStatic } from 'hono/bun'
diff --git a/docs/getting-started/cloudflare-workers.md b/docs/getting-started/cloudflare-workers.md
@@ -3,7 +3,7 @@
 [Cloudflare Workers](https://workers.cloudflare.com) is a JavaScript edge runtime on Cloudflare CDN.
 
 You can develop the application locally and publish it with a few commands using [Wrangler](https://developers.cloudflare.com/workers/wrangler/).
-Wrangler includes trans compiler, so we can write the code with TypeScript.
+Wrangler includes transcompiler, so we can write the code with TypeScript.
 
 Let’s make your first application for Cloudflare Workers with Hono.
 
@@ -273,7 +273,7 @@ The same is applied to Bearer Authentication Middleware, JWT Authentication, or
 
 Before deploying code to Cloudflare via CI, you need a Cloudflare token. You can manage it from [User API Tokens](https://dash.cloudflare.com/profile/api-tokens).
 
-If it's a newly created token, select the **Edit Cloudflare Workers** template, if you already have another token, make sure the token has the corresponding permissions(No, token permissions are not shared between Cloudflare Pages and Cloudflare Workers).
+If it's a newly created token, select the **Edit Cloudflare Workers** template. If you already have another token, make sure the token has the corresponding permissions. (Note: token permissions are not shared between Cloudflare Pages and Cloudflare Workers).
 
 then go to your GitHub repository settings dashboard: `Settings->Secrets and variables->Actions->Repository secrets`, and add a new secret with the name `CLOUDFLARE_API_TOKEN`.
 
diff --git a/docs/getting-started/deno.md b/docs/getting-started/deno.md
@@ -212,7 +212,7 @@ Hono is available on both [npm](https://www.npmjs.com/package/hono) and [JSR](ht
 }
 ```
 
-To use middleware you need to use the [Deno directory](https://docs.deno.com/runtime/fundamentals/configuration/#custom-path-mappings) syntaxt in the import
+To use middleware you need to use the [Deno directory](https://docs.deno.com/runtime/fundamentals/configuration/#custom-path-mappings) syntax in the import.
 
 ```json
 {
diff --git a/docs/getting-started/google-cloud-run.md b/docs/getting-started/google-cloud-run.md
@@ -2,13 +2,13 @@
 
 [Google Cloud Run](https://cloud.google.com/run) is a serverless platform built by Google Cloud. You can run your code in response to events and Google automatically manages the underlying compute resources for you.
 
-Google Cloud Run uses containers to run your service. This means you can use any runtime you like (E.g., Deno or Bun) by providing a Dockerfile. If no Dockerfile is provided Google Cloud Run will use the default Nodejs buildpack.
+Google Cloud Run uses containers to run your service. This means you can use any runtime you like (E.g., Deno or Bun) by providing a Dockerfile. If no Dockerfile is provided Google Cloud Run will use the default Node.js buildpack.
 
 This guide assumes you already have a Google Cloud account and a billing account.
 
 ## 1. Install the CLI
 
-When working with Google Cloud Platform it is easiest to work with the [gcloud CLI](https://cloud.google.com/sdk/docs/install).
+When working with Google Cloud Platform, it is easiest to work with the [gcloud CLI](https://cloud.google.com/sdk/docs/install).
 
 For example, on MacOS using Homebrew:
 
@@ -127,8 +127,8 @@ gcloud run deploy my-app --source . --allow-unauthenticated
 
 If you want to deploy using Deno or Bun runtimes (or a customised Nodejs container), add a `Dockerfile` (and optionally `.dockerignore`) with your desired environment.
 
-For information on containerizing please refer to:
+For information on containerizing, please refer to:
 
-- [Nodejs](/docs/getting-started/nodejs#building-deployment)
+- [Node.js](/docs/getting-started/nodejs#building-deployment)
 - [Bun](https://bun.com/guides/ecosystem/docker)
 - [Deno](https://docs.deno.com/examples/google_cloud_run_tutorial)
diff --git a/docs/getting-started/lambda-edge.md b/docs/getting-started/lambda-edge.md
@@ -8,7 +8,7 @@ Hono supports Lambda@Edge with the Node.js 18+ environment.
 
 When creating the application on Lambda@Edge,
 [CDK](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-cdk.html)
-is useful to setup the functions such as CloudFront, IAM Role, API Gateway, and others.
+is useful to set up the functions such as CloudFront, IAM Role, API Gateway, and others.
 
 Initialize your project with the `cdk` CLI.
 
diff --git a/docs/getting-started/nodejs.md b/docs/getting-started/nodejs.md
@@ -2,7 +2,7 @@
 
 [Node.js](https://nodejs.org/) is an open-source, cross-platform JavaScript runtime environment.
 
-Hono was not designed for Node.js at first. But with a [Node.js Adapter](https://github.com/honojs/node-server) it can run on Node.js as well.
+Hono was not designed for Node.js at first, but with a [Node.js Adapter](https://github.com/honojs/node-server), it can run on Node.js as well.
 
 ::: info
 It works on Node.js versions greater than 18.x. The specific required Node.js versions are as follows:
@@ -281,7 +281,7 @@ Apps with a front-end framework may need to use [Hono's Vite plugins](https://gi
 
 ### Dockerfile
 
-Here is an example of a nodejs Dockerfile.
+Here is an example of a Node.js Dockerfile.
 
 ```Dockerfile
 FROM node:22-alpine AS base
diff --git a/docs/getting-started/webassembly-wasi.md b/docs/getting-started/webassembly-wasi.md
@@ -4,7 +4,7 @@
 
 In practice:
 
-- Languages (like Javascript) _compile to_ WebAssembly (`.wasm` files)
+- Languages (like JavaScript) _compile to_ WebAssembly (`.wasm` files)
 - WebAssembly runtimes (like [`wasmtime`][wasmtime] or [`jco`][jco]) enable _running_ WebAssembly binaries
 
 While core WebAssembly has _no_ access to things like the local filesystem or sockets, the [WebAssembly System Interface][wasi]
@@ -30,17 +30,16 @@ both StarlingMonkey and Hono, **Hono works \*out of the box with WASI-enabled We
 The WebAssembly JS ecosystem provides tooling to make it easy to get started building WASI-enabled WebAssembly components:
 
 - [StarlingMonkey][sm] is a fork of [SpiderMonkey][spidermonkey] that compiles to WebAssembly and enables components
-- [`componentize-js`][componentize-js] turns Javascript ES modules into WebAssembly components
-- [`jco`][jco] is a multi-tool that builds components, generates types, and runs components in environments like NodeJS or the browser
+- [`componentize-js`][componentize-js] turns JavaScript ES modules into WebAssembly components
+- [`jco`][jco] is a multi-tool that builds components, generates types, and runs components in environments like Node.js or the browser
 
 ::: info
-Webassembly has an open ecosystem and is open source, with core projects stewarded primarily by the [Bytecode Alliance][bca] and it's members.
+WebAssembly has an open ecosystem and is open source, with core projects stewarded primarily by the [Bytecode Alliance][bca] and its members.
 
 New features, issues, pull requests and other types of contributions are always welcome.
 :::
 
-While a starter for Hono on WebAssembly is not yet available, you can start a WebAssembly Hono project just
-like any other:
+While a starter for Hono on WebAssembly is not yet available, you can start a WebAssembly Hono project just like any other:
 
 ::: code-group
 
@@ -85,7 +84,7 @@ bun add -D @bytecodealliance/jco @bytecodealliance/componentize-js @bytecodealli
 To ensure your project uses ES modules, ensure `type` is set to `"module"` in `package.json`
 :::
 
-After entering the `my-app` folder, install dependencies, and initialize Typescript:
+After entering the `my-app` folder, install dependencies, and initialize TypeScript:
 
 ::: code-group
 
@@ -110,7 +109,7 @@ bun i
 
 :::
 
-Once you have a basic typescript configuration file (`tsconfig.json`), please ensure it has the following configuration:
+Once you have a basic TypeScript configuration file (`tsconfig.json`), please ensure it has the following configuration:
 
 - `compilerOptions.module` set to `"nodenext"`
 
@@ -143,12 +142,9 @@ Feel free to use any other bundlers that you're more comfortable with (`rolldown
 
 ## 2. Set up WIT interface & dependencies
 
-[WebAssembly Inteface Types (WIT)][wit] is an Interface Definition Language ("IDL") that governs what functionality
-a WebAssembly component uses ("imports"), and what it provides ("exports").
+[WebAssembly Inteface Types (WIT)][wit] is an Interface Definition Language ("IDL") that governs what functionality a WebAssembly component uses ("imports"), and what it provides ("exports").
 
-Amongst the standardized WIT interfaces, [`wasi:http`][wasi-http] is for dealing with HTTP requests (whether it's
-receiving them or sending them out), and since we intend to make a web server, our component must declare the use
-of `wasi:http/incoming-handler` in it's [WIT world][wit-world]:
+Amongst the standardized WIT interfaces, [`wasi:http`][wasi-http] is for dealing with HTTP requests (whether it's receiving them or sending them out), and since we intend to make a web server, our component must declare the use of `wasi:http/incoming-handler` in it's [WIT world][wit-world]:
 
 First, let's set up the component's WIT world in a file called `wit/component.wit`:
 
@@ -160,11 +156,9 @@ world component {
 }
 ```
 
-Put simply, the WIT file above means that our component "providers" the functionality of "receiving"/"handling incoming"
-HTTP requests.
+Put simply, the WIT file above means that our component "providers" the functionality of "receiving"/"handling incoming" HTTP requests.
 
-The `wasi:http/incoming-handler` interface relies on upstream standardized WIT interfaces (specifications
-on how requests are structured, etc).
+The `wasi:http/incoming-handler` interface relies on upstream standardized WIT interfaces (specifications on how requests are structured, etc).
 
 To pull those third party (Bytecode Alliance maintained) WIT interaces, one tool we can use is [`wkg`][wkg]:
 
@@ -196,11 +190,9 @@ wit
 
 ## 3. Hello Wasm
 
-To build a HTTP server in WebAssembly, we can make use of the [`jco-std`][jco-std] project, which
-contains helpers that make the experience very similar to the standard Hono experience.
+To build a HTTP server in WebAssembly, we can make use of the [`jco-std`][jco-std] project, which contains helpers that make the experience very similar to the standard Hono experience.
 
-Let's fulfill our `component` world with a basic Hono application as a WebAssembly component in
-a file called `src/component.ts`:
+Let's fulfill our `component` world with a basic Hono application as a WebAssembly component in a file called `src/component.ts`:
 
 ```ts
 import { Hono } from 'hono'
@@ -222,7 +214,7 @@ export { incomingHandler } from '@bytecodealliance/jco-std/wasi/0.2.6/http/adapt
 
 ## 4. Build
 
-Since we're using Rolldown (and it's configured to handle Typescript compilation), we can use it to build and bundle:
+Since we're using Rolldown (and it's configured to handle TypeScript compilation), we can use it to build and bundle:
 
 ::: code-group
 
@@ -245,8 +237,7 @@ bun build --target=bun --outfile=dist/component.js ./src/component.ts
 :::
 
 ::: info
-The bundling step is necessary because WebAssembly JS ecosystem tooling only currently supports a single JS file,
-and we'd like to include Hono along with related libraries.
+The bundling step is necessary because WebAssembly JS ecosystem tooling only currently supports a single JS file, and we'd like to include Hono along with related libraries.
 
 For components with simpler requirements, bundlers are not necessary.
 :::
@@ -278,7 +269,7 @@ bun run jco componentize -w wit -o dist/component.wasm dist/component.js
 To run your Hono WebAssembly HTTP server, you can use any WASI-enabled WebAssembly runtime:
 
 - [`wasmtime`][wasmtime]
-- `jco` (runs in NodeJS)
+- `jco` (runs in Node.js)
 
 In this guide, we'll use `jco serve` since it's already installed.
 
@@ -324,11 +315,9 @@ You should see output like the following:
 ```
 
 ::: info
-`jco serve` works by converting the WebAssembly component into a basic WebAssembly coremodule,
-so that it can be run in runtimes like NodeJS and the browser.
+`jco serve` works by converting the WebAssembly component into a basic WebAssembly coremodule, so that it can be run in runtimes like Node.js and the browser.
 
-This process is normally run via `jco transpile`, and is the way we can use JS engines like NodeJS
-and the browser (which may use V8 or other Javascript engines) as WebAssembly Component runtimes.
+This process is normally run via `jco transpile`, and is the way we can use JS engines like Node.js and the browser (which may use V8 or other Javascript engines) as WebAssembly Component runtimes.
 
 How `jco transpile` is outside the scope of this guide, you can read more about it in [the Jco book][jco-book]
 :::
diff --git a/docs/guides/faq.md b/docs/guides/faq.md
@@ -4,7 +4,7 @@ This guide is a collection of frequently asked questions (FAQ) about Hono and ho
 
 ## Is there an official Renovate config for Hono?
 
-The Hono teams does not currently maintain [Renovate](https://github.com/renovatebot/renovate) Configuration.
+The Hono team does not currently maintain [Renovate](https://github.com/renovatebot/renovate) Configuration.
 Therefore, please use third-party renovate-config as follows.
 
 In your `renovate.json` :
diff --git a/docs/guides/jsx-dom.md b/docs/guides/jsx-dom.md
@@ -2,7 +2,7 @@
 
 `hono/jsx` supports not only server side but also client side. This means that it is possible to create an interactive UI that runs in the browser. We call it Client Components or `hono/jsx/dom`.
 
-It is fast and very small. The counter program in `hono/jsx/dom` is only 2.8KB with Brotli compression. But, 47.8KB for React.
+It is fast and very small. The counter program in `hono/jsx/dom` is only 2.8KB with Brotli compression, but 47.8KB for React.
 
 This section introduces Client Components-specific features.
 
diff --git a/docs/guides/jsx.md b/docs/guides/jsx.md
@@ -136,7 +136,7 @@ const List = () => (
 )
 ```
 
-Or you can write it with `<></>` if it set up properly.
+Or you can write it with `<></>` if it sets up properly.
 
 ```tsx
 const List = () => (
@@ -386,8 +386,8 @@ The `scriptNonce` value will be automatically added to any `<script>` tags gener
 
 ## Integration with html Middleware
 
-Combine the JSX and html middlewares for powerful templating.
-For in-depth details, consult the [html middleware documentation](/docs/helpers/html).
+Combine the JSX and HTML middlewares for powerful templating.
+For in-depth details, consult the [HTML middleware documentation](/docs/helpers/html).
 
 ```tsx
 import { Hono } from 'hono'
diff --git a/docs/guides/middleware.md b/docs/guides/middleware.md
diff --git a/docs/guides/rpc.md b/docs/guides/rpc.md
diff --git a/docs/guides/testing.md b/docs/guides/testing.md
diff --git a/docs/guides/validation.md b/docs/guides/validation.md
diff --git a/docs/helpers/css.md b/docs/helpers/css.md
diff --git a/docs/helpers/proxy.md b/docs/helpers/proxy.md
