diff --git a/content/blog/45dr-postmortem/index.md b/content/blog/45dr-postmortem/index.md
index 3bc88dd..086eb06 100644
--- a/content/blog/45dr-postmortem/index.md
+++ b/content/blog/45dr-postmortem/index.md
@@ -1,4 +1,5 @@
 {% extends "../../../layouts/post.html" %}
+{% import "../../../layouts/macros.html" as macros %}
 
 {% block article %}
 # 45 Day Rogulike Postmortem
@@ -11,11 +12,11 @@ My method of generating a dungeon level was disappointingly simple: [binary spac
  
 The field of view (FOV) system is simple as well. This system uses another tilemap for rendering visibility. Each tile initializes to black with full opacity (`RGBA(0, 0, 0, 1)`). The opacity value will change to 0.5 or 0 depending on visibility.
 
-![Tile opacity values](./values.png)
+{{ macros::image(src="./values.png", alt="Tile opacity values") }}
 
 When the target entity's FOV updates each turn, the visibility tilemap checks a target's FOV. I used a C# `HashSet` of coordinates to represent each entity's FOV. The visibility system monitors a target's FOV and sets each visible tile's opacity to 0. Previously visible tiles' opacities are then set to 0.5. Determining which tiles were previously visible is as simple as taking the difference between the last turn's visible tiles and this turn's visible tiles (Previous - Current).
 
-![Venn diagram of opacity values](./opacity-venn.png)
+{{ macros::image(src="./opacity-venn.png", alt="Venn diagram of opacity values") }}
 
 Once the dungeon finishes generating, all "decorators" are notified and begin placing objects through the dungeon. Decorators include the player, enemies, stairs, and treasure chests. These components became a dumping ground for hacky code and workarounds, so I tried to ensure this code didn't influence any other systems.
 
diff --git a/content/blog/convenient-unity-attributes/index.md b/content/blog/convenient-unity-attributes/index.md
index de50881..a39e423 100644
--- a/content/blog/convenient-unity-attributes/index.md
+++ b/content/blog/convenient-unity-attributes/index.md
@@ -1,4 +1,5 @@
 {% extends "../../../layouts/post.html" %}
+{% import "../../../layouts/macros.html" as macros %}
 
 {% block article %}
 # Convenient Unity Attributes
@@ -11,6 +12,7 @@ I won't attempt to iterate every useful attribute in Unity's library. I encourag
 
 [Documentation](https://docs.unity3d.com/2022.1/Documentation/ScriptReference/HeaderAttribute.html)
 
+
 This simple and effective attribute will display a header above the property to which it is applied.
 
 ```cs
@@ -26,7 +28,7 @@ public class Movement : MonoBehaviour
 }
 ```
 
-![Example of the inspector](./header-example.png)
+{{ macros::image(src="./header-example.png", alt="Example of the inspector") }}
 
 # Space
 
@@ -51,7 +53,7 @@ public class Example : MonoBehaviour
 
 A 10-pixel space is between `maxHealth` and `shield`.
 
-![Screenshot of example component](./space-example.png)
+{{ macros::image(src="./space-example.png", alt="Screenshot of example component") }}
 
 
 # Tooltip
@@ -71,7 +73,7 @@ public class Movement : MonoBehaviour
 }
 ```
 
-![Example of tooltip attribute](./tooltip-example.png)
+{{ macros::image(src="./tooltip-example.png", alt="Screenshot of tooltip attribute") }}
 
 Although in this particular case, I may suggest a custom attribute that appends "m/s" to the end of the field, a tooltip can provide this type of clarity and context.
 
@@ -99,7 +101,7 @@ public class Example : MonoBehaviour
 }
 ```
 
-![Example of Range attribute](./range-example.png)
+{{ macros::image(src="./range-example.png", alt="Example of Range attribute") }}
 
 The inspector is now enforcing the restriction and displaying it as a slider between the two values. I find this helps reason about the range better than a number field.
 
@@ -199,7 +201,7 @@ public class Movement : MonoBehaviour
 }
 ```
 
-![Example of HideInInspector attribute](./hideininspector-example.png)
+{{ macros::image(src="./hideininspector-example.png", alt="Example of HideInInspector attribute") }}
 
 
 # RequireComponent
@@ -225,6 +227,6 @@ public class Movement : MonoBehaviour
 
 Unity adds a `Rigidbody` if it doesn't already exist on the GameObject. Attempting to remove `Rigidbody` will cause an error.
 
-![Screenshot of the error message](./remove-requiredcomponent.png)
+{{ macros::image(src="./remove-requiredcomponent.png", alt="Example of the error message") }}
 {% endblock article %}
 
diff --git a/static/css/main.css b/static/css/main.css
index 1f77419..2d03a46 100644
--- a/static/css/main.css
+++ b/static/css/main.css
@@ -115,6 +115,10 @@ li::before {
     color: var(--list-marker-color);
 }
 
+img {
+    max-width: 100%;
+}
+
 pre {
     padding: 0.5rem;
     overflow: auto;
@@ -261,5 +265,7 @@ nav li::before {
     flex-grow: 1;
 }
 
-
+.image-link {
+    display: block;
+}