<p><strong>Technical:</strong></p>

<p>The only technical difference is, that predefined-transforms have a different directory structure:</p>

<pre><code>/asset-folder/_transform-name/image.jpg
</code></pre>

<p>whereas inline-transforms use dimensions:</p>

<pre><code>/asset-folder/_300x100/image.jpg
</code></pre>

<p>Personally I like the first one more.</p>

<p>.</p>

<p><strong>Users:</strong></p>

<p>The difference for users is, that only predefined-transforms can be selected in RichText-fields.</p>

<p>.</p>

<p><strong>Development:</strong></p>

<p>I often use just a few transforms on my projects, so I find maintaining them from the backend easier.</p>

<p>But you could just as well create yourself an include-file to have everything in one place:</p>

<p><code>/_includes/image_transforms.html</code>:</p>

<pre><code>{% set transform_1 = {
    mode: 'crop',
    width: 100,
    height: 100,
    quality: 100,
    position: 'top-center'
} %}

{% set transform_2 = {
    mode: 'crop',
    width: 50,
    height: 50,
    quality: 75,
    position: 'center-center'
} %}
</code></pre>

<p><code>/some_template.html</code>:</p>

<pre><code>{% include "_includes/image_transforms" %}

&lt;img src="{{ asset.getUrl(transform_1) }}"&gt;

&lt;img src="{{ asset.getUrl(transform_2) }}"&gt;
</code></pre>

CC BY-SA 3.0
2016-02-11T04:26:48.793Z
The development section here is a little wrong - you can't set variables in an include and have them available in the template that includes the include (includes receive a _copy_ of the context, not the actual context, to work in)
Jeremy Daalder
CC BY-SA 3.0
2014-06-13T13:17:42.327Z
2014-06-13T13:17:42.327Z
Victor
<p>If you need the image transforms in Rich Text fields, you have to define them in the control panel, as Josh said. Apart from that, I feel that it's much more flexible to define them at the template level. </p>

<p>The main advantage is that you can then make the transform dynamic, based on the current template or the current content that is displayed. One example is being able to do <a href="https://github.com/aelvan/RESS-Toolbox-Craft" rel="nofollow">transforms based on the users device/screen size</a>. Another is being able to give the client the ability to <a href="http://craftcookbook.net/recipes/120" rel="nofollow">define crop positions on a per image basis</a>.</p>

CC BY-SA 3.0
2014-06-13T13:28:49.557Z
2014-06-13T13:28:49.557Z
André Elvan
<p>They should effectively be doing the same thing. Control Panel Transforms are simply predefined transforms. In both cases, they should perform equally after the first render because Craft stores the transformed image for later reuse.</p>

CC BY-SA 3.0
2014-06-13T12:59:03.413Z
2014-06-13T12:59:03.413Z
Bryan Redeagle
<p>Both methods essentially do exactly the same thing to the image however there are two advantages to pre-defining them in the control panel:</p>

<ol>
<li>You can just call a transform handle in your templates instead of having to define the whole transform model</li>
<li>They are then available to be used in supported field types e.g. in the Rich Text field type you can select an existing image transform when inserting an image</li>
</ol>

<p>As you already mentioned the advantages that I can see to defining them in the templates are version control and the lack of needing a database.</p>

<p>I've started defining them all in the templates for the development phase and then when we move to staging I go and add all the ones we're using to the control panel. </p>

CC BY-SA 3.0
2014-06-13T13:28:28.113Z
The Rich Text Field benefit is a very valid point!
jnowland
CC BY-SA 3.0
2014-06-13T13:29:30.120Z
I've yet to find a client who will use it but still, its a lovely feature!
Josh Angell
CC BY-SA 3.0
2014-06-13T13:08:57.173Z
2014-06-13T13:08:57.173Z
Josh Angell
<p>In Craft you can do two types of image transforms:</p>

<p><strong>1. Control Panel Transforms:</strong></p>

<pre><code>Via: Settings → Assets → Image Transforms
</code></pre>

<p><strong>2. Inline Transforms in your Templates</strong></p>

<p>I’m currently using 100% inline transforms as they can be version controlled and seem to work better across different dev environments.</p>

<p>Are there any benefits of using Control Panel Transforms over using Inline Template Transforms in your Templates?</p>

<image-transforms><assets><git>
What are the Pros and Cons to each image transform technique?
# What are the Pros and Cons to each image transform technique?

(Asked by: username_0 on 2014-06-13)

In Craft you can do two types of image transforms:
1. Control Panel Transforms:
Via: Settings → Assets → Image Transforms

2. Inline Transforms in your Templates
I’m currently using 100% inline transforms as they can be version controlled and seem to work better across different dev environments.
Are there any benefits of using Control Panel Transforms over using Inline Template Transforms in your Templates?

**Tags:** image-transforms, assets, git

---

## 4 answers

### Answer by username_5 on 2014-06-13. Score: 9 | Accepted answer

Both methods essentially do exactly the same thing to the image however there are two advantages to pre-defining them in the control panel:

1. You can just call a transform handle in your templates instead of having to define the whole transform model
2. They are then available to be used in supported field types e.g. in the Rich Text field type you can select an existing image transform when inserting an image

As you already mentioned the advantages that I can see to defining them in the templates are version control and the lack of needing a database.

I've started defining them all in the templates for the development phase and then when we move to staging I go and add all the ones we're using to the control panel.

> **Comments:**
> **username_0**: The Rich Text Field benefit is a very valid point!  
> **username_5**: I've yet to find a client who will use it but still, its a lovely feature!  

---

### Answer by username_1 on 2014-06-13. Score: 6

Technical:
The only technical difference is, that predefined-transforms have a different directory structure:
/asset-folder/_transform-name/image.jpg

whereas inline-transforms use dimensions:
/asset-folder/_300x100/image.jpg

Personally I like the first one more.
.
Users:
The difference for users is, that only predefined-transforms can be selected in RichText-fields.
.
Development:
I often use just a few transforms on my projects, so I find maintaining them from the backend easier.
But you could just as well create yourself an include-file to have everything in one place:
/_includes/image_transforms.html:
{% set transform_1 = {
    mode: 'crop',
    width: 100,
    height: 100,
    quality: 100,
    position: 'top-center'
} %}

{% set transform_2 = {
    mode: 'crop',
    width: 50,
    height: 50,
    quality: 75,
    position: 'center-center'
} %}

/some_template.html:
{% include "_includes/image_transforms" %}

> **Comments:**
> **username_2**: The development section here is a little wrong - you can't set variables in an include and have them available in the template that includes the include (includes receive a _copy_ of the context, not the actual context, to work in)  

---

### Answer by username_3 on 2014-06-13. Score: 3

If you need the image transforms in Rich Text fields, you have to define them in the control panel, as Josh said. Apart from that, I feel that it's much more flexible to define them at the template level.

The main advantage is that you can then make the transform dynamic, based on the current template or the current content that is displayed. One example is being able to do [transforms based on the users device/screen size](https://github.com/aelvan/RESS-Toolbox-Craft). Another is being able to give the client the ability to [define crop positions on a per image basis](http://craftcookbook.net/recipes/120).


---

### Answer by username_4 on 2014-06-13. Score: 2

They should effectively be doing the same thing. Control Panel Transforms are simply predefined transforms. In both cases, they should perform equally after the first render because Craft stores the transformed image for later reuse.


---

