Feature-Requests

You already allow theming of fonts and spacing at the template level but one major piece lacking is color theming. Problem with current approach : we can define colors at account level and apply in theme. However updating these colors does not update the template or modules. Solution part 1: Allow us to name colors and then use variable names instead of hex values if desired. Solution part 2: Allow overriding of the account colors at the template level. this way we could implement different color themes for our templates without redesigning and duplicating every module.

We often use comments in Stripo to discuss internal topics such as initial email changes, design fixes, or layout iterations. These discussions are relevant only for Stripo users who build the emails. Once the email is ready, we usually share it with other stakeholders, such as product managers or management, for final review and approval. At this stage, they still see all internal, design-related comments (even if they are resolved), which are not relevant and can be confusing. It would be very helpful to split comments into two types: – internal comments – visible only to Stripo users working on the email in the editor – external comments – visible to external reviewers This would make collaboration cleaner, reduce noise for stakeholders, and improve the overall review experience.

It would be helpful to add a feature that allows users to switch logos automatically between dark mode and light mode. Many brands don’t have a mid-tone logo that works well on both backgrounds. I’ve tried handling this using HTML-based logo switching, but it’s not a reliable solution. It often causes inconsistencies or errors across different platforms such as Apple Mail and Outlook. A better solution would be to allow users to upload two separate logo versions: One logo optimized for light mode (e.g., black text/logo) One logo optimized for dark mode (e.g., white text/logo) The system could then automatically switch between these logos based on the user’s theme preference. This would ensure better brand visibility, consistency across platforms, and a smoother experience for everyone.

When you adjust corner rounding on desktop, it also changes it for mobile. If you want it to be different for mobile so you edit it in the mobile editor, this also changes it in the desktop editor. Please could you make this editable separately, in the same way padding can be different between desktop and mobile.

Pulls the latest posts directly into the newsletter, keeping content fresh without manual updates. Users interact by “scratching” an area to uncover offers, codes, or surprises, boosting engagement. Allows subscribers to vote on products or preferences directly in the email, providing instant insights and higher interaction.

To be able to have one section with multiple rows of different numbers of columns - allowing for unified styling of a section with diverse content.

When users choose a custom HTML block, it usually means standard blocks cannot solve their use case. In many cases, this becomes a blocker. Here is a real example from practice: – The current menu block does not work properly on mobile devices in responsive, multi-column layouts. – A user needs a very simple footer structure: logo in the left column and a menu in the right column (stacking on mobile). This cannot be achieved with standard Stripo blocks. – As a result, the user switches to a custom HTML block with custom CSS. – The footer is required in every email, so the user saves it as a module. – However, when saved as a module, the CSS breaks and the element no longer works as intended. This creates a hard limitation. Users cannot solve the problem with standard blocks, and at the same time, Stripo prevents them from implementing a custom solution. Please allow saving and reusing CSS for custom HTML blocks inside modules so custom solutions remain functional and reusable across emails. For custom HTML blocks, CSS is a critical part of the solution. Without preserving the associated CSS, the custom code cannot work as intended. It would be much better if Stripo saved and reused custom HTML together with its CSS as a single, intact module.

We received a suggestion from a customer to add a possibility to сreate UTM parameters on the project level. Once they are added, the customer can activate UTMs in the email, and they will be set up automatically from the project settings. We would like to check if this feature will be suitable and useful for you, so please feel free to vote or send your comments about it here.

In most emails you need at least two button styles – for the CTAs and for secondary actions like learn more/read some article etc. Now it is possible to create only one button style in general settings. As a result every time when you create new emails you have to style secondary buttons completely from scratch. Moreover, there is a bug that often makes secondary buttons inherit some properties from the General settings when sending email or previewing it instead of its own properties. Most often it is hover properties. It would be great if you allow creating multiple button styles in general settings using a repeater button: By default every email has one button style. But you can click "+" and create more. Each button will have it's own CSS class and will not inherit anything from other buttons. When you add a button to the page you can choose: a) Choose one of the styles that you made in general settings b) Set parameters manually for this button but make sure that it's hover state does not inherit properties but has its own style for it.

Currently in Stripo's emails all UTM parameters are set for the whole email. However, UTM content is a unique parameter that helps you identify where exactly someone clicked: (utm_content=hero or utm_content=article-title or utm_content=cta-button). It will be really useful if for all blocks that support links you add another field under the URL field specifically for UTM content parameter. It should probably only appear if you activate UTMs for your whole email (otherwise without other UTM parameters it does not make sense to have it in your emails).