diff --git a/contract-dev/gas.mdx b/contract-dev/gas.mdx
index 8662aac0c..37c0d9b51 100644
--- a/contract-dev/gas.mdx
+++ b/contract-dev/gas.mdx
@@ -137,7 +137,7 @@ let sizeMsg = computeDataSize(
 );
 
 let fwdFee = getForwardFee(
-    sizeMsg.cells - 1, 
+    sizeMsg.cells - 1,
     sizeMsg.bits - msg.toCell().bits(),
     isAccountInMasterchain
 );
@@ -157,7 +157,7 @@ In Tolk, both computations can be performed with a call to `msg.send()` with mod
 
 If the size of the outgoing message is bounded by the size of the incoming message, we can estimate the forward fee of an outgoing message to be no larger than the forward fee of the incoming message, that was already computed by TVM. Thus, we don't have to calculate it again. Note that this estimation is correct only for a contract system in the same workchain, because gas prices depend on the workchain.
 
-```tolk
+```tolk title="Tolk"
 fun onInternalMessage(in: InMessage) {
     val fwdFee = in.originalForwardFee;
     // ...
@@ -170,7 +170,7 @@ Assume the contract receives a message with an unknown size and forwards it furt
 
 For this case, in Tolk, there is a function `calculateForwardFeeWithoutLumpPrice()`. In TVM, it's implemented as [`GETFORWARDFEESIMPLE`](/tvm/instructions#f83c-getforwardfeesimple). This function does not take `lumpPrice` into account.
 
-```tolk
+```tolk title="Tolk"
 fun onInternalMessage(in: InMessage) {
     val origFwdFee = in.originalForwardFee;
 
diff --git a/contract-dev/upgrades.mdx b/contract-dev/upgrades.mdx
index ef4bfdee6..8e1c3b9b4 100644
--- a/contract-dev/upgrades.mdx
+++ b/contract-dev/upgrades.mdx
@@ -52,7 +52,7 @@ If there's not enough Toncoin to execute action phase with the code update, but
 
 ### Example
 
-```tolk expandable
+```tolk title="Tolk" expandable
 struct (0x1111) UpgradeContract {
     data: cell?
     code: cell?
@@ -77,8 +77,8 @@ fun onInternalMessage(in: InMessage) {
             }
         }
 
-        else => { 
-            // just accept TON 
+        else => {
+            // just accept TON
         }
     }
 }
@@ -116,7 +116,7 @@ The admin can also send `RejectUpgrade` at any time to cancel a pending upgrade.
 
 ### Example
 
-```tolk expandable
+```tolk title="Tolk" expandable
 struct UpgradeContract {
     data: cell?
     code: cell?
@@ -171,7 +171,7 @@ fun onInternalMessage(in: InMessage) {
 
         ApproveUpgrade => {
             var storage = lazy Storage.load();
-            
+
             assert (in.senderAddress == storage.adminAddress) throw 100;
             assert (storage.CurrentRequest != null) throw 301;
             assert (storage.CurrentRequest!.timestamp + storage.timeout < blockchain.now()) throw 302;
@@ -189,8 +189,8 @@ fun onInternalMessage(in: InMessage) {
             }
         }
 
-        else => { 
-            // just accepted tons 
+        else => {
+            // just accepted tons
         }
     }
 }
@@ -244,9 +244,9 @@ The key mechanism: `setTvmRegisterC3()` switches the code register so the migrat
 
 The example shows a counter contract that adds a metadata field through a hot upgrade. The storage structure changes: the original version stores only `adminAddress` and `counter`. The new version adds `metadata` and reorders fields.
 
-Original contract (`main.tolk`):
+Original contract:
 
-```tolk expandable
+```tolk title="main.tolk" expandable
 import "@stdlib/tvm-lowlevel"
 
 struct (0x00001111) HotUpgrade {
@@ -260,7 +260,7 @@ type AllowedMessages =
     | HotUpgrade
     | IncreaseCounter
 
-// migration function must have method_id 
+// migration function must have method_id
 @method_id(2121)
 fun hotUpgradeData(additionalData: cell?) { return null; }
 
@@ -273,12 +273,12 @@ fun onInternalMessage(in: InMessage) {
         HotUpgrade => {
             var storage = lazy Storage.load();
             assert (in.senderAddress == storage.adminAddress) throw 1111;
-            
+
             contract.setCodePostponed(msg.code);
 
             setTvmRegisterC3(transformSliceToContinuation(msg.code.beginParse()));
             hotUpgradeData(msg.additionalData);
-        } 
+        }
 
         IncreaseCounter => {
             var storage = lazy Storage.load();
@@ -286,8 +286,8 @@ fun onInternalMessage(in: InMessage) {
             storage.save();
         }
 
-        else => { 
-            // just accept TON 
+        else => {
+            // just accept TON
         }
     }
 }
@@ -317,9 +317,9 @@ The `hotUpgradeData()` function in the original code returns `null` because it d
 1. `setTvmRegisterC3()` switches register C3 to the new code immediately
 1. `hotUpgradeData(msg.additionalData)` is called and runs with the new code
 
-New contract with migration (`new.tolk`):
+New contract with migration:
 
-```tolk
+```tolk title="new.tolk"
 import "@stdlib/tvm-lowlevel"
 
 struct (0x00001111) HotUpgrade {
@@ -333,13 +333,13 @@ type AllowedMessages =
     | HotUpgrade
     | IncreaseCounter
 
-// migration function must have method_id 
+// migration function must have method_id
 @method_id(2121)
-fun hotUpgradeData(additionalData: cell?) {  
+fun hotUpgradeData(additionalData: cell?) {
     var oldStorage = lazy oldStorage.load();
 
     assert (additionalData != null) throw 1112;
-    
+
     var storage = Storage {
         adminAddress: oldStorage.adminAddress,
         counter: oldStorage.counter,
@@ -368,12 +368,12 @@ fun onInternalMessage(in: InMessage) {
         HotUpgrade => {
             var storage = lazy Storage.load();
             assert (in.senderAddress == storage.adminAddress) throw 1111;
-            
+
             contract.setCodePostponed(msg.code);
 
             setTvmRegisterC3(transformSliceToContinuation(msg.code.beginParse()));
             hotUpgradeData(msg.additionalData);
-        } 
+        }
 
         IncreaseCounter => {
             var storage = lazy Storage.load();
@@ -381,8 +381,8 @@ fun onInternalMessage(in: InMessage) {
             storage.save();
         }
 
-        else => { 
-            // just accept TON 
+        else => {
+            // just accept TON
         }
     }
 }
diff --git a/ecosystem/api/price.mdx b/ecosystem/api/price.mdx
index 11fee839c..12bd82030 100644
--- a/ecosystem/api/price.mdx
+++ b/ecosystem/api/price.mdx
@@ -39,7 +39,7 @@ take_pool_state#bddd4954 query_id:uint64 reserve0:Coins reserve1:Coins total_sup
 
 Here is a smart contract snippet in [Tolk](/languages/tolk) illustrating how you can send the 'provide' message:
 
-```tolk
+```tolk title="Tolk"
 struct (0x6e24728d) ProvideDeDustPool {
     queryId: uint64
     doIncludeAssets: bool
diff --git a/foundations/addresses/derive.mdx b/foundations/addresses/derive.mdx
index 68b4040e9..066fb599e 100644
--- a/foundations/addresses/derive.mdx
+++ b/foundations/addresses/derive.mdx
@@ -15,7 +15,7 @@ The `StateInit` is distinct from the account's current state. It is the initial
 
 If it's known how to compose the contract's initial `code` and `data`, it's enough to follow the general algorithm mentioned above as is. Code and data form a `StateInit`, and the [workchain](/foundations/addresses/overview#workchain-id) is usually hardcoded. Below is one of the most common patterns when `code` is a constant cell known in advance and `data` is composed at runtime.
 
-```tolk expandable
+```tolk title="Tolk" expandable
 // Compose an address builder
 fun calculateAddress(
     code: cell,
@@ -63,7 +63,7 @@ The `calculateAddress` function uses the [`AutoDeployAddress`](/languages/tolk/f
 
 When working with the [contract sharding](/contract-dev/contract-sharding) pattern, child contracts usually have a `StateInit` that depends on the parent. In the example below, the dependence is implemented by adding the parent address to the child `StateInit`. The same logic from the [simple on-chain](#on-chain-simple) case works here, and only `getData` has to be changed.
 
-```tolk expandable
+```tolk title="Tolk" expandable
 // Compose an address builder using the AutoDeployAddress built-in.
 fun calculateAddress(code: cell, data: cell, workchain: int): builder {
     val addr = AutoDeployAddress {
@@ -108,7 +108,7 @@ A [vanity contract](/contract-dev/vanity) allows _customizing_ the address of a
 
 In this case, there is no real correlation between the data the contract holds and its final address. So there is no way to actually _derive_ the address. The only option left is to define a constant with the actual address that is obtained in advance.
 
-```tolk
+```tolk title="Tolk"
 // Constant address in raw format.
 const VANITY_ADDRESS_RAW: address = address("0:4de24b95c1c3c9b6a94231460716192c7d2b4e444ca6ae9a98bc5c4b3fcdef3f");
 
@@ -129,7 +129,7 @@ This may seem similar to the [vanity](#on-chain-vanity) case, but it serves a di
 
 The logic here is more similar to the [simple](#on-chain-simple) case. The only difference is the additional `toShard` field.
 
-```tolk expandable
+```tolk title="Tolk" expandable
 // Compose an address builder using the AutoDeployAddress built-in.
 fun deriveAddress(target: address, prefixLength: int): builder {
     val code = getCode();
diff --git a/foundations/messages/external-out.mdx b/foundations/messages/external-out.mdx
index 994bd6403..0137ffbce 100644
--- a/foundations/messages/external-out.mdx
+++ b/foundations/messages/external-out.mdx
@@ -41,7 +41,7 @@ As outbound external messages do not carry any Toncoin value, the price of their
 
 In Tolk, outbound external messages may be composed using the `createExternalLogMessage` function.
 
-```tolk
+```tolk title="Tolk"
 tolk 1.2
 
 struct(0x10) ValueWasDeposited {
diff --git a/standard/tokens/nft/deploy.mdx b/standard/tokens/nft/deploy.mdx
index c2772290e..9a8e7a888 100644
--- a/standard/tokens/nft/deploy.mdx
+++ b/standard/tokens/nft/deploy.mdx
@@ -169,7 +169,7 @@ To deploy an item from a smart contract, send a message from the contract to the
 
 The following example is a minimal smart contract that only implements the item deployment logic. In real deployments, this is integrated into a larger flow.
 
-```tolk
+```tolk title="Tolk"
 // SnakeString describes a (potentially long) string inside a cell;
 // short strings are stored as-is, like "my-picture.png";
 // long strings are nested refs, like "xxxx".ref("yyyy".ref("zzzz"))
diff --git a/standard/tokens/nft/nft-2.0.mdx b/standard/tokens/nft/nft-2.0.mdx
index c57386c30..3271da2f8 100644
--- a/standard/tokens/nft/nft-2.0.mdx
+++ b/standard/tokens/nft/nft-2.0.mdx
@@ -187,7 +187,7 @@ The TEP-66 standard does not define the body of internal messages used to delive
 
 Below is an example contract snippet written in Tolk:
 
-```tolk
+```tolk title="Tolk"
 // You should retrieve these values by calling the collection's getter method beforehand
 struct Storage {
     numerator: uint16
diff --git a/tvm/get-method.mdx b/tvm/get-method.mdx
index aeeb9cd46..57a8ca472 100644
--- a/tvm/get-method.mdx
+++ b/tvm/get-method.mdx
@@ -48,7 +48,7 @@ PROGRAM{
 
 The above is equivalent to the following Tolk code, which compiles to almost identical Fift code.
 
-```tolk
+```tolk title="Tolk"
 fun main() { }
 
 get fun get_x(): int {