# Embedding plain SVG results in incorrect rendering

**URL:** <https://forum.inductiveautomation.com/t/embedding-plain-svg-results-in-incorrect-rendering/55778>\
**Category:** Ignition\
**Tags:** perspective, ignition81\
**Created:** [February 4, 2022, 7:50pm UTC](https://forum.inductiveautomation.com/t/embedding-plain-svg-results-in-incorrect-rendering/55778 "2022-02-04T19:50:08Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [February 4, 2022, 8:03pm UTC](https://forum.inductiveautomation.com/t/embedding-plain-svg-results-in-incorrect-rendering/55778/2 "2022-02-04T20:03:05Z")

</div>

The short version:  
The SVG spec is _immense_. Really, truly, ridiculously immense.  
We employ some extremely limited parsing when you drop an SVG in and choose to embed it. If there’s anything in the SVG we don’t recognize, we don’t _reject_ it - we just don’t assign it any meaning in the output.  
For _some_ things, that might be plausible to change on our side. For more exotic SVG features, it’ll probably never happen when embedding in this way; instead, just leave your SVG intact and display it as an image; in that case we don’t know or care about the contents of your SVG, and it’s up to the browser to render it correctly.

---

_[View the full topic](https://forum.inductiveautomation.com/t/embedding-plain-svg-results-in-incorrect-rendering/55778)._
