diff --git a/Dynamic-filtering:-Benefits-of-blocking-3rd-party-iframe-tags.md b/Dynamic-filtering:-Benefits-of-blocking-3rd-party-iframe-tags.md
index 2299a97..4178ecf 100644
--- a/Dynamic-filtering:-Benefits-of-blocking-3rd-party-iframe-tags.md
+++ b/Dynamic-filtering:-Benefits-of-blocking-3rd-party-iframe-tags.md
@@ -26,7 +26,7 @@ Blocking 3rd-party `iframe` tags will typically cause little web page breakage,
 
 Ultimately, if a site breaks because it really does need legitimate 3rd-party `<iframe>`, then un-blocking `<iframe>` for a specific site is only one click away:
 
-<p align="center"><img src="https://cloud.githubusercontent.com/assets/585534/9136522/4455038c-3ce5-11e5-9e91-e8843f15c143.png" /><br><sup>3rd-party &lt;iframe&gt; tags blocked by default for all sites,<br><b>except</b> for the current site (this was for github.com) -- **using a `noop` rule**.</sup></p>
+<p align="center"><img src="https://cloud.githubusercontent.com/assets/585534/9136522/4455038c-3ce5-11e5-9e91-e8843f15c143.png" /><br><sup>3rd-party &lt;iframe&gt; tags blocked by default for all sites,<br><b>except</b> for the current site (this was for github.com) -- <b>using a noop rule</b>.</sup></p>
 
 But even in this case, the best advice would be to actually find from which specific hostname iframe tags are required, and to create a `noop` rule *only* for this hostname, rather than unblock all 3rd-party `iframe` tags on the site -- though this approach is better suited to advanced users.