diff --git a/guide/src/reference/attributes/on-rust-exports/function-attributes.md b/guide/src/reference/attributes/on-rust-exports/function-attributes.md
index 6e07cd2c9f9..74ebdc494b4 100644
--- a/guide/src/reference/attributes/on-rust-exports/function-attributes.md
+++ b/guide/src/reference/attributes/on-rust-exports/function-attributes.md
@@ -42,7 +42,7 @@ export function build_person(personName: string): Promise<Person>;
 As you can see, using function attributes, we can now return a JS/TS object without ever using `wasm_bindgen` macro on `Person` struct that would have generated a JS/TS class object in the bindings which might not be the desired outcome for every case, you can see as well that instead of handcoding the full documentation for `build_person()` with all JSDoc/TSDoc tags and syntax, we can just write specific description for each individual component of the function and as a result end up with a fully typed and documented function in the bindings.
 
 **IMPORTANT NOTE**
-Types that are provided using `#[wasm_bindgen(unchecked_return_type)]` and `#[wasm_bindgen(unchecked_param_type)]` aren't checked as these attributes' identifiers entail, meaning they will end up in the function's signature and docs bindings exactly as they have been specified and there are no checks/validation for them in place, so only because a user uses '#[wasm_bindgen(unchecked_param_type = "number")]' for example, it doesn't necessarily mean it's actually going to be a value of number type, therefore validation and checks between the value and its type should be handled by the user and the responsibility of using them correctly and carefully relies solely on the user.
+Types that are provided using `#[wasm_bindgen(unchecked_return_type)]` and `#[wasm_bindgen(unchecked_param_type)]` aren't checked as these attributes' identifiers entail, meaning they will end up in the function's signature and docs bindings exactly as they have been specified and there are no checks/validation for them in place, so only because a user uses `#[wasm_bindgen(unchecked_param_type = "number")]` for example, it doesn't necessarily mean it's actually going to be a value of number type, therefore validation and checks between the value and its type should be handled by the user and the responsibility of using them correctly and carefully relies solely on the user.
 
 Let's look at some more exmaples in details:
 ```rust