Copy-paste between emails: What actually comes with the element

You’re managing three campaigns at the same time: this week’s promotion, a series of reminders scheduled for Tuesday, and a newsletter that the client expects to receive by lunchtime. All three templates are in the same editor and need the same banner-and-button block you’ve already created for the first one.

You could create them manually, which would take ten minutes per email: insert an image, copy the text, recreate the spacing, create a button, and add a link, just to recreate what already exists in the next tab. If you save it as a module, it’ll end up in a library you probably haven’t looked at in months, alongside blocks you’ve long since forgotten you ever created.

Another consideration is that even if you choose the first option and recreate a block that already exists, the result won’t always match the original. Some elements that made the original block look the way it should may be located one level higher: in a container or structure rather than within the block itself. A merge tag that displayed a name in one email might also turn into plain text in another if that tag isn’t defined in the project where you inserted the text.

Regardless of which editor you’re using, the result of copying depends on what actually belonged to the element and what it merely borrowed from where it was previously located. The color you set for the button belongs to the button. The background that the container inherited from the stripe belongs to the stripe. All the problems that arise when moving blocks between emails and tabs are often the results of this boundary appearing where you didn’t expect it.

Not just one editor’s problem

This issue isn’t specific to any particular tool you use to create email newsletters. The options for such features on the market are similar, with slightly different forms.

Fixed-tree approach. The copying unit is the row: while you can select an individual image within it, you always copy the row itself, the root of the copied structure. Copying to the other email takes four steps: select, copy, switch, and paste, with no library step in between.

Whatever style attributes are applied directly to the elements within the row survive the move, but any styling inherited by the row from its original template becomes re-evaluated against the new template, so the block can change colors on paste without a touch. What makes it confusing is that the selection highlight suggests that you copied the image, and the paste confirms the opposite. The row is the smallest thing that can leave the template: a column, an image, or a single button has no way out on its own.

The source wins the library. The unit of copying is whatever you save: typically, a full row or a module. There are four actions involved in the process: save, assign a name to the object, locate it within the library, and insert the object into your new email.

The object retains its original colors and fonts wherever it is inserted, while the destination template’s styles are applied only where nothing is set by the object. It always appears the same way, no matter which email you place it within, even if that’s not what’s called for by its surroundings.

The library with a taxonomy cost. It follows the same source-wins rule mentioned above but requires more than a name to save. You need both a category and some tags before the saving process can be completed, so a one-time transfer from one email to another requires creating a filing system first.

The layer nobody controls

The clipboard itself creates an additional, less obvious point of failure. Copying via the system clipboard can be done if the browser grants access, and this access is not guaranteed with every copy attempt.

When access is denied, some tools fall back to storing a copy locally, a method that works only within a single domain. Paste the text within the same project and you won’t even notice that the system has switched to the alternative method. Try pasting that same text outside the domain and the operation will yield no result.

You click, but nothing happens: there is no error message, no indication of failure of any sort.

What Stripo built to close that gap

The Stripo modular system has always addressed the issue of creating an object once and reusing it repeatedly. However, it now also addresses an intermediate step: moving an object exactly once without saving it.

Now, you can copy any block, container, structure, or entire stripe from one template and paste it directly into another without adding it to the library.

One keyboard shortcut for any tab

Select an element, copy it, switch to another tab, and paste it. This keyboard shortcut works the same way, whether you’re moving a single button or an entire section, because Stripo recognizes the type of element you’ve copied and correctly reproduces it in another location.

This feature works via the system clipboard, the same one used for all other copy-and-paste operations on your computer, so it works not only between tabs open in the same browser but also between windows and browsers. If a browser blocks this access, Stripo seamlessly switches to a local copy — the fallback option tied to the domain mentioned earlier.

If you copy a three-column product block from one marketing campaign and paste it into a newsletter that is set up using only one column, Stripo automatically adapts the width of the copied block to that of the email template it ends up in.

Let’s return to the three tabs mentioned at the beginning. Moving the Banner block from the advertising campaign to the reminder series and the newsletter takes just four steps: select, copy, switch tabs, and paste. There is no need to rename anything or save it as a separate file, and the module library retains its original size.

After moving the block, you should check not the layout itself but the elements the block merely referenced rather than contained directly: the personalization tag, the display condition, and the language version.

What moves with the element

The same own-versus-inherited logic from the market applies here, just made precise. 

A blue button will always be exactly blue because the blue color was specified for that button alone. The background color of a container, however, doesn’t carry over the same way if the color was never explicitly set but instead inherited from its stripe.

Merge tags, conditions, and language versions

A few elements behave slightly differently, but it all boils down to the same rule we’ve already mentioned: what belongs to an element is moved along with it, while what it merely references remains tied to the location of that reference.

A merge tag is a reference to something defined at the project level, not on the element itself. Copy the element into a project where this same tag exists and it will work immediately. Copy it to a new location and Stripo won’t have anything to reference yet, so the tag will appear as plain text until you add it to that project.

Predefined conditions work the same way. They are tied to the project’s shared condition library, so a copied condition becomes a standalone custom condition in the new location. It continues to work exactly as it was designed to. It’s just no longer linked to the original library, just as a copied paragraph is no longer linked to the document from which it originated.

Language versions follow the logic of what’s displayed on the screen: the version you’re currently viewing is the one that gets copied. Add other languages to the new email, just as you would if you were creating them there from scratch.

When copying isn’t the right choice 

It works in favor of copy-pasting as long as you do it only once and know precisely where it will land. As soon as you need to make another run, copy-pasting no longer works.

Should you have to use the same footer for a dozen emails, or should someone other than yourself have to change the footer next month, it is better to use the module: you change the content in the module and all your emails get updated automatically, rather than changing a dozen paste-ins one by one.

Wrapping up

Now, placing a Banner block from one email into the other two takes just a few clicks: the styles and layout remain the same, and there’s no need to name anything or save anything for later.

The only habit worth developing alongside this is: after inserting something that uses a merge tag, display condition, or language version, take a few extra seconds to make sure those elements are positioned exactly as you expected. 

Design, layout, and spacing are inherent to the element itself and move with it. Merge tags, conditions, and different language versions are all references that remain bound to the project from which they originate.