diff --git a/guides/source/action_text_overview.md b/guides/source/action_text_overview.md
index 2950a87d3b446..6d398ffa49231 100644
--- a/guides/source/action_text_overview.md
+++ b/guides/source/action_text_overview.md
@@ -65,7 +65,7 @@ After the installation is complete, a Rails app using Webpacker should have the
Additionally, this `actiontext.scss` file should be imported into your stylesheet pack.
- ```
+ ```scss
// application.scss
@import "./actiontext.scss";
```
diff --git a/guides/source/asset_pipeline.md b/guides/source/asset_pipeline.md
index f189b773d7dbb..b1914c1e8c3b5 100644
--- a/guides/source/asset_pipeline.md
+++ b/guides/source/asset_pipeline.md
@@ -898,7 +898,7 @@ You can also set this value through an [environment
variable](https://en.wikipedia.org/wiki/Environment_variable) to make running a
staging copy of your site easier:
-```
+```ruby
config.action_controller.asset_host = ENV['CDN_HOST']
```
@@ -1013,7 +1013,7 @@ the cache will store the object before invalidating the cache. The `max-age`
value is set to seconds with a maximum possible value of `31536000` which is one
year. You can do this in your Rails application by setting
-```
+```ruby
config.public_file_server.headers = {
'Cache-Control' => 'public, max-age=31536000'
}
diff --git a/guides/source/autoloading_and_reloading_constants.md b/guides/source/autoloading_and_reloading_constants.md
index 332f3b4eb3108..57c404b7e19d3 100644
--- a/guides/source/autoloading_and_reloading_constants.md
+++ b/guides/source/autoloading_and_reloading_constants.md
@@ -172,7 +172,7 @@ Let's see other situations that involve stale class or module objects.
Check this Rails console session:
-```
+```ruby
> joe = User.new
> reload!
> alice = User.new
@@ -198,7 +198,7 @@ Bottom line: **do not cache reloadable classes or modules**.
Applications can safely autoload constants during boot using a reloader callback:
-```
+```ruby
Rails.application.reloader.to_prepare do
$PAYMENT_GATEWAY = Rails.env.production? ? RealGateway : MockedGateway
end
diff --git a/guides/source/configuring.md b/guides/source/configuring.md
index 34b941b182b11..cd43e9bd91859 100644
--- a/guides/source/configuring.md
+++ b/guides/source/configuring.md
@@ -1381,7 +1381,7 @@ You can find more information in the [Unicorn readme](https://bogomips.org/unico
Once you've configured the application server, you must proxy requests to it by configuring your web server appropriately. For example your NGINX config may include:
-```
+```nginx
upstream application_server {
server 0.0.0.0:8080;
}
diff --git a/guides/source/debugging_rails_applications.md b/guides/source/debugging_rails_applications.md
index d70a2893fc61b..04b6684595298 100644
--- a/guides/source/debugging_rails_applications.md
+++ b/guides/source/debugging_rails_applications.md
@@ -331,7 +331,7 @@ application server, and you will be placed at the debugger's prompt `(byebug)`.
Before the prompt, the code around the line that is about to be run will be
displayed and the current line will be marked by '=>', like this:
-```
+```ruby
[1, 10] in /PathTo/project/app/controllers/articles_controller.rb
3:
4: # GET /articles
diff --git a/guides/source/engines.md b/guides/source/engines.md
index c8313f1a5d264..bd1fc3b4a6518 100644
--- a/guides/source/engines.md
+++ b/guides/source/engines.md
@@ -1338,7 +1338,7 @@ were inside the engine:
You can also specify these assets as dependencies of other assets using Asset
Pipeline require statements in processed files:
-```
+```css
/*
*= require blorgh/style
*/
diff --git a/guides/source/generators.md b/guides/source/generators.md
index db6503b03df06..8368cd111f7b9 100644
--- a/guides/source/generators.md
+++ b/guides/source/generators.md
@@ -468,7 +468,7 @@ Adding Command Line Arguments
-----------------------------
Rails generators can be easily modified to accept custom command line arguments. This functionality comes from [Thor](https://www.rubydoc.info/github/erikhuda/thor/master/Thor/Base/ClassMethods#class_option-instance_method):
-```
+```ruby
class_option :scope, type: :string, default: 'read_products'
```
diff --git a/guides/source/layouts_and_rendering.md b/guides/source/layouts_and_rendering.md
index 6ec5613e3fcab..62e8b9a73ad8b 100644
--- a/guides/source/layouts_and_rendering.md
+++ b/guides/source/layouts_and_rendering.md
@@ -754,7 +754,7 @@ head :bad_request
This would produce the following header:
-```
+```http
HTTP/1.1 400 Bad Request
Connection: close
Date: Sun, 24 Jan 2010 12:15:53 GMT
@@ -773,7 +773,7 @@ head :created, location: photo_path(@photo)
Which would produce:
-```
+```http
HTTP/1.1 201 Created
Connection: close
Date: Sun, 24 Jan 2010 12:16:44 GMT
diff --git a/guides/source/security.md b/guides/source/security.md
index 3a3bad270e4d7..9c9972b57d8e0 100644
--- a/guides/source/security.md
+++ b/guides/source/security.md
@@ -734,7 +734,7 @@ This JavaScript code will simply display an alert box. The next examples do exac
These examples don't do any harm so far, so let's see how an attacker can steal the user's cookie (and thus hijack the user's session). In JavaScript you can use the `document.cookie` property to read and write the document's cookie. JavaScript enforces the same origin policy, that means a script from one domain cannot access cookies of another domain. The `document.cookie` property holds the cookie of the originating web server. However, you can read and write this property, if you embed the code directly in the HTML document (as it happens with XSS). Inject this anywhere in your web application to see your own cookie on the result page:
-```
+```html
```
@@ -798,7 +798,7 @@ As a second step, _it is good practice to escape all output of the application_,
Network traffic is mostly based on the limited Western alphabet, so new character encodings, such as Unicode, emerged, to transmit characters in other languages. But, this is also a threat to web applications, as malicious code can be hidden in different encodings that the web browser might be able to process, but the web application might not. Here is an attack vector in UTF-8 encoding:
-```
+```html
```
@@ -811,7 +811,7 @@ _In order to understand today's attacks on web applications, it's best to take a
The following is an excerpt from the [Js.Yamanner@m](http://www.symantec.com/security_response/writeup.jsp?docid=2006-061211-4111-99&tabid=1) Yahoo! Mail [worm](http://groovin.net/stuff/yammer.txt). It appeared on June 11, 2006 and was the first webmail interface worm:
-```
+```html