diff --git a/visualization/README.md b/visualization/README.md
index dd6da0191bde00f95268d49ff551167d0c5cdf37..990751f979e912a6d9fe1aad7d318aad7be86911 100644
--- a/visualization/README.md
+++ b/visualization/README.md
@@ -33,7 +33,7 @@ After visualization is complete, you can interact with the graph in the followin
         * If you now map offences to punishments, you get this:
 ![something](./obc2kg_1720_mapped.png?raw=true)
 
-### Some comments on the architecture with special emphasis on _special node types_
+## Some comments on the architecture with special emphasis on _special node types_
 Initially, the idea was to make the visualization suite as generic as possible, i.e. that almost any JSON file that adhered to the basic structure of
 
     {"nodes": [{id: 1, label: "Something", attributes: {...}}, {...}], "edges": [{id: 1, source: 1, target: 2}, {...}]
@@ -48,7 +48,7 @@ These variables maintain a somehwat generic code base by simply defining only _o
 
 In a future update, we might expand this idea by allowing you to freely change a config file that simply gets read by the suite, instead of having to change the code in the nested directory.
 
-#### **$rootScope.json\_mapping**
+### **$rootScope.json\_mapping**
 
 The first variable is intended to define a mapping between the JSON-specific nomenclature of keys to the generic graph-theoretical terminology.
 
@@ -62,7 +62,7 @@ For example, if you call your nodes "knoten" and your edges "verbindungen", you
     
 This way, every time the suite needs to access nodes, it can do so by checking this mapping on how _you_ refer to nodes.
 
-#### **$rootScope.special\_node\_types**
+### **$rootScope.special\_node\_types**
 The second variable declares some nodes to be "special" in the sense that those are nodes that should be displayed differently from undeclared nodes.
 Notice that this automatically displays nodes with the default shape and color if they do not match the condition given in the variable.