A customer reported an issue where the link in an email they received was not displayed properly. Despite multiple checks on different Outlook accounts, the link appeared to be functioning normally. However, the customer reported seeing HTML code instead of a clickable link within the email's table. The customer sent us a copy of the email, and i could see that the button instead of containing all well done has this:
[%3ca%20href=]https://app.mydomain.com/unit?user=70a92653-555c-4daf-966d-8b2c062e133c&unit=97aec2fb-e21a-47b2-9731-be0c2a9acabd&campaign=f0e0ef90-ac23-465a-8f02-42e4a77feb1b&cohort=ed0307f6-31d7-4537-a3d5-a1c6a35b19a9" style=" display: block; height: 100%; width: 100%; text-decoration: none; color: #ffffff; "> Click to Access
It's like that outlook attemped to rewrite the <a href= itself breaking it all. Do anyone had similar troubles with Outlook for Windows? Is it an antivirus, or do we need to ensure something in our <!-- mso comment?
Check for any additional software in Outlook like COM or web add-ins installed (or VBA macros) that could cause such issues. For example, most antivirus software adds their bits to Outlook.
Outlook.com specifically will turn a link that doesn't have a proper protocol at the start into this: [www.sitewithoutinitialprotocol.com]Text for Link
So perhaps what is happening is it doesn't think the link you've written is correct. What's the code in the initial email for the link? The href attribute must have a http:// or https:// (though it does look like you have this).
Perhaps also check the character/characters in this text, it may be there's a hidden non-breaking space or something unusual. You can paste it all into regexr.com, into the 'expression' area, and check each character precisely.
Related
Although Outlook sends e-mails as HTML by default, Microsoft seems to want to make it hard for us to write that HTML ourselves. One important reason for using HTML is to keep the size of an e-mail down when inserting an image by using an <img> tag to access the image from online instead of inserting the image itself in the body of the e-mail.
Several sources [e.g., 1, 2] say that the way to do this is to use "Insert as Text" to insert a file containing the HTML code. But as of Office 2016, the "Insert as Text" option is no longer available by default. Fortunately though, there are also sources [e.g., 3] that show how to get it back.
However, when I tried this, Outlook did not interpret my HTML. So, for example, if I make a file containing the line:
<img src="https://www.lenetek.com/blog/how-to-create-html-emails-in-outlook/images/attach_file.jpg" alt="Random online image">
and then use "Insert as Text" to insert that line in my e-mail, the result is just that line of code, not the image. What am I doing wrong?
(As indicated by the alt attribute, the image file in that example is just a random online image that appears in one of the articles referenced above. I have no affiliation with that website.)
The answer is very simple. In a way, it's obvious, but in another way, it's not.
The answer is that each segment of HTML code inserted has to be a complete HTML file, including the <!DOCTYPE>, <HTML> and <body> tags, not just the desired HTML code. The reason this is not obvious is because if you insert multiple code segments, each one has to be a complete HTML file, which is something you would never do when actually writing HTML. I presume that what is happening is that when Outlook detects a valid HTML file being "Inserted as Text", it strips the opening and closing <!DOCTYPE>, <HTML> and <body> tags and then inserts the code that was between them -- as HTML, not as text.
So, the solution I found was that instead of the single line of code shown in the question, I need to "Insert as Text" a file containing:
<!DOCTYPE html>
<html>
<body>
<img src="https://www.lenetek.com/blog/how-to-create-html-emails-in-outlook/images/attach_file.jpg" alt="Random online image">
</body>
</html>
When I insert that as text in my e-mail, I see the image, not the code.
In all the sources I found online that said to use "Insert as Text" to insert HTML in Outlook, none of them said it had to be a complete HTML file instead of just the desired code. So maybe this Q&A will be helpful to someone else, if I'm not the only person who had to scratch my head for a long time before thinking of that.
========================
Added details about using HTML in the e-mail:
As pointed out in the Lenetek article linked in the question, Outlook does not support all HTML tags. In particular, for embedding images, I have found:
When sending from Outlook:
Outlook does not support <figure> and <FigCaption>. I found that an image and caption placed in those tags were rendered inline, just ignoring the tags. For floating to the right margin, I found I was able to get the same results by replacing <figure> with <table> and then placing the image and its caption each inside of <TR><TD>...</TD></TR>.
When receiving in Outlook:
There are differences in how different e-mail clients interpret HTML, which is probably why some e-mails come with a link at the top for viewing the e-mail in one's browser. In particular, I've read that Outlook is not well behaved in this regard. And that was the case with my right-floated image referred to above.
After doing the "Insert as Text" trick, the image appeared correctly at the right margin in the draft e-mail in Outlook, but when it was sent, the CSS style float attribute was ignored and the table appeared by itself at the left margin with no text wrapped around it. I was able to fix this by, in the <table> tag, replacing the style attribute float: right; with the old-fashioned HTML attribute align="right". With that, the image and caption appeared correctly at the right margin when received in Outlook. I have not tested what it looks like in other e-mail clients.
In addition to NewSites answer, I want to point out, that in current Outlook 365 versions the option for "Insert as text" does not appear in the standard settings. The mentioned function under the "attach" tab does NOT offer the "Insert as text" option in the modal window.
For this to work, you will have to add a new tab yourself to the ribbon and add the "Attach" button to this new tab. Once you click this newly added button, you will get a modal with the little dropdown next to the "Insert" button.
I had this same issue and have been so frustrated. It's actually super easy. The trick is to use outlook.live.com. Type any word in the body, highlight it, right click, select "inspect". The code will appear and the word you typed in the body of the email should be highlighted. Right click in the code and select "edit as html." Then, in the code, highlight the word you typed in the body and replace it with your code. Voila! (I learned that here: https://youtu.be/yZOYRhB6ONs)
I had issues displaying the linked image while generating outlook email using HTML code. Somehow it works on a couple of machines, but most didn't show the image.
Kept on researching knowing the problem is with Outlook interpreting the HTML code. And then I reached this thread and the #NewSites answer really nailed it. Just added the line <!DOCTYPE HTML> at the top of my HTML code and all are working perfectly now.
Outlook 365 (2022 Update)
For Outlook 365, the Attach option needs to be enabled manually. Modify the Command Ribbon from inside the message, not the main Outlook window:
Note this option is Attach File without subcommands, i.e. the "classic" Attach File.
From there you can choose Insert as Text as the HTML snippet will show up as processed, not just code.
Outlook version for this post: Microsoft® Outlook® for Microsoft 365 MSO (Version 2202 Build 16.0.14931.20652) 64-bit
I have defined an HTML email template that has an anchor tag which its href attribute is assigned to a handlebars.js
Something like this:
<td class="body-text" align="left" class="padding">For the latest information on this order, please click here.<br></td>
I'm using Litmus to preview all the Email clients available but notice that in Outlook 365 it would show the content inside the email between brackets.
After some research, I came with this issue in their official repository. So, Outlook expects to add the full URL but I'm sending a handlebars.js variable instead. How could I solve this issue?
This may be related to this issue:
http://freshinbox.com/blog/outlook-com-removes-placeholder-links-in-email/
Outlook.com and Office 365 don't like dummy or empty links and subsequently you'll see broken templates in Litmus tests.
For testing purposes, it'll be best to follow the steps in the article I linked and test again.
We have Ruby script that fetch and parse reply emails from our clients and putting them on appropriate client object in application.
For that purpose we send email to client with specific "hidden" code/id inside 1x1 pixel img tag (in similar way tracking pixel technology works) when clients reply to email, they quote our original email with code/id inside. And when we get client reply we can detect that hidden code from img tag, and process it accordingly. This works fine except when clients are replying from Outlook 2013.
Outlook 2013 removes image data containing code/id, and put something like "Image removed by sender." so we cannot detect see code/id anymore.
Also tried, making a image from base64 and even encoding code/id inside base64 image, but we got same result.
We tried different solutions, like making custom tags with class name contain code/id. Those custom tags are removed too, and replaced with something like < o:p >< /o:p >
We tried to put code/id inside invisible div, in inline css and various css tricks, and in this case Outlook just removes invisibility of div, and code/id is visible in email content.
There is a option that code/id is visible text inside body or subject, but we would like that this code/id be stays invisible to the clients.
It seems like its almost impossible to pass some hidden data trough reply email from MS Outlook.
Is there any way that we can pass this code/id trough reply email from outlook, without outlook removing it or making it visible?
Thank you.
Unless the data is visible (one way or another), chances are Outlook (or rather Word-light used for editing emails) will remove it.
White text on white background would probably work...
<img src=3D"https://t.yesware.com/t/58c8a29bcdf01103c9661815ef20eff8d=
f34a1b3/556ad713ae0cb0b15199a455f1fa5dfd/spacer.gif" style=3D"border:0; wid=
th:0; height:0; overflow:hidden;" width=3D"0" height=3D"0"><img src=3D"http=
://t.yesware.com/t/58c8a29bcdf01103c9661815ef20eff8df34a1b3/556ad713ae0cb0b=
15199a455f1fa5dfd/spacer.gif" style=3D"border:0; width:0; height:0; overflo=
w:hidden;" width=3D"0" height=3D"0">
I will address this dry-snitching code in a bit
Yesware is a paid service that allows you to track when and where the recipient of your email opens that email, every single time that they do or if they forward it to someone else, you will get the IP address and device type of each of those opens as well.
I've used Yesware for years, this is the first time that it has peeked it's little head out. In an email chain involving my Gmail hosted email and someone we will call Quarles. The first email I sent Quarles went normally, I received notification from Yesware that Quarles opened it from an iPhone. No further notifications came from YesWare which is impossible because he has replied twice.
I discovered in the latest email thread, under my second reply, Image removed by sender.Image removed by sender.
Below my third reply, Error! File name not specified.Error! Filename not specified.
I viewed the headers and, damn the luck, Quarles is using Outlook on a Mac Microsoft-MacOutlook/10.c.0.180410
What I am curious about is what Quarles sees on his end. Because the gif is not gone, the code is still there in our thread untouched. I know because if I open the email thread from another device (non-sending device) I get the notification that someone opened the email. So, what is preventing the code from calling home? Is it his MacOutlook? Is it an add-on he's got?
I am seriously considering having my husband write something better than Yesware. He's not a programmer but he is a SysAdmin so he'll figure it out. Besides, the stupid programs he has designed looked like crap anyway so why not write code for something that is supposed to remain unseen.
Oops, gotta go, if he catches me on stackoverflow he's gonna freak.. ;)
I'm sending an HTML mail from my app, this mail contains URLs, is there a way to prevents from mail clients to show these URLs as links?
for example:
<table>
<tbody>
<tr>
<td>http://www.google.com</td>
</tr>
</tbody>
</table>
will generate" http://www.google.com
instead I want it to generate a static text.
any thoughts?
This is a feature of some mail clients and there's no foolproof way to stop them from doing whatever they want with the message contents.
You could try to trick the mail clients by wrapping the addresses in empty tags and hope that they aren't smart enough to see through it:
<td><span>http</span><span>://</span>www.<span>google.</span>com</td>
Use a "zero width space" character:
It does as the name implies. It adds a space in your string but the space takes up zero width so instead of looking like two strings, it looks like one.
I have found the accepted answer doesn't work for Outlook 2013. I have had success with the following:
http<a href='#' style='text-decoration:none; color:#000;'>://www.google.</a>com
Setting the style cursor:default is not honored by Outlook 2013, but if you only make the middle of the url a hyperlink then a user can still select the link text without the cursor pointer appearing.
I'd say that largely depends on the mail client and thus is beyond your control. The only option would be to not make it a URL. E.g. write www.google.com (which the user can copy/paste just like the URL.
I didn't have any luck in preventing MacMail and Yahoo Mail from creating links out of any text string ending in .com (or other domain extension). After hours of testing (even 'href=""' and 'href="#"' did not work), I finally inserted my own URL and then manipulated the CSS and inline styles to remove the mail clients' link styling.
Adding in hidden line break elements in the right places seems to have fixed this for me (for now) in almost all clients, including desktop Outlook, according to Litmus's tests (Apple Mail desktop looks like the main exception).
https:<br style="display: none;"/>//www.w3<br style="display: none;"/>.org/TR/2020/WD-WCAG22-20200227/
I'm sending an e-mail newsletter in HTML.
Inside the HTML I have something like
<img height='70' width='70' style='display:block' src='myDomain.com/imageName.png'>
When I open the newsletter with Thunderbird or Outlook, the image is being displayed. However, when I open it with Gmail, no image is shown.
I'm not sure if it's about the proxy that Gmail uses for security reasons or if it's something else. Either way, I'd like to know if anyone ever came across this and if so, how it was solved.
Late to the party but here goes... I have experienced this problem as well and it was solved with the following:
Including the scheme in the src url (using "//" does not work - use full scheme EG: "https://")
Including width and height attributes
Including style="display:block" attribute
Including both alt and title attributes
EG:
<img src="https://static.mydomain.com/images/logo.png" alt="Logo" title="Logo" style="display:block" width="200" height="87" />
For me, the problem was using svg images. I switched them to png and it worked.
Google only allows images which are coming from trusted source .
So I solved this issue by hosting my images in google drive and using its url as source for my images.
Example:
with:
http://drive.google.com/uc?export=view&id=FILEID'>
to form URL please refer here.
Please also check your encoding: Google encodes spaces as + instead of %20. This may result in an invalid image link.
You might have them turned off in your gmail settings, heres the link to change them https://support.google.com/mail/answer/145919?hl=en
Also gmail may be blocking the images thinking they are suspicious.
from the link above.
How Gmail makes images safe
Some senders try to use externally linked images in harmful ways, but
Gmail takes action to ensure that images are loaded safely. Gmail
serves all images through Google’s image proxy servers and transcodes
them before delivery to protect you in the following ways:
Senders can’t use image loading to get information like your IP
address or location. Senders can’t set or read cookies in your
browser. Gmail checks your images for known viruses or malware. In
some cases, senders may be able to know whether an individual has
opened a message with unique image links. As always, Gmail scans every
message for suspicious content and if Gmail considers a sender or
message potentially suspicious, images won’t be displayed and you’ll
be asked whether you want to see the images.
Try to add title and alt properties to your image.... Gmail and some others blocks images without some attributes.. and it is also a logic to include your email to be read as spam.
I noticed that Google was stripping the src attribute from my img tags. I tried every answer on this page - with no luck.
What finally worked for me was replacing img tags with divs that have background images. For example, instead of:
<img style="height: 24px; width: 24px; display: block;" src="IMAGE SOURCE"/>
I replaced it with:
<div style="height: 24px; width: 24px; display: block; background: url(IMAGE SOURCE); background-size: contain;"></div>
Hope this helps others who spent way too long pulling their hair out over this.
In addition to what was said by Howard
You have to keep in mind that Google encodes spaces as +
To avoid this, the ulr must be encoded in RFC 3986, which means spaces encoded at %20, for example:
https://example.com/My Folder/image 1.jpg
to
https://example.com/My%20Folder/image%201.jpg
I had the same issue and for me it was because I was using an SVG image, once I changed to a JPG or PNG, it worked. Maybe this can assist someone who will come across the same issue. It seems Gmail doesn't support SVG images.
HTTP or HTTPS should be full address
background-image: url(http://fulladdress.com/ca/1/product_assets/T/C/X/M/K/NMTCXMK_mu.jpg)
var mailOptions = {
from: 'fulladdress#gmail.com',
to: emails,
subject: 'i super another ma node mailer cool test',
text: 'That was easy!',
html: '<div style="background-image: url(http://fulladdress.com/ca/1/product_assets/T/C/X/M/K/NMTCXMK_mu.jpg);width:500px;height:500px">ascfas</div>'
};
I know Gmail already fix all the problem above, the alt and stuff now.
And this is unrelated to the question but probably someone experiences the same as me.
So my web designer use "image" tag instead of "img", but the symptom was the same. It works on outlook but not Gmail.
It takes me an hour to realize. Sigh, such a waste of time.
So make sure the tag is "img" not "image" as well.
My issue was similar.
This is what my experience has been on testing the IMG tag on gmail
(assuming most of the organization's would have a dev qa and prod server.)
I had to send emails to customers on their personal email id's and we could see that gmail would add something of its own like following to src attribute of img tag. Now when we were sending these images from our dev environment they would never render on gmail and we were always curious why?
https://ci7.googleusercontent.com/proxy/AEF54znasdUhUYhuHuHuhHkHfT7u2w5zsOnWJ7k1MwrKe8pP69hY9W9eo8_n6-tW0KdSIaG4qaBEbcXue74nbVBysdfqweAsNNmmmJyTB-JQzcgn1j=s0-d-e2-ft#https://www.prodserver.com/Folder1/Images/OurImage.PNG
so an image sent to my gmail id as following never worked for me
<img src="https://ci7.googleuser....Blah.Blah..https://devserver.com/Folder1/Images/OurImage.PNG">
and our dev server we can't render this image by hitting following URL on Chrome(or any browser).
https://www.devserver.com/folder1/folder2/myactualimage.jpg
now as long as the src has www on it worked all the time and we didnt had to add any other attributes.
<img src="https://www.**prodserver**.com/folder1/folder2/myactualimage.jpg">
I was using Cloudflare. As soon as I disabled the proxy for my host's website IP address images in Gmail appeared immediately.
I have now added a new firewall rule to allow requests where the URI contains 'googleimageproxy' and everything is working fine.
I am even later to this party, but after spending about 2 hours trying everything imaginable and not having any luck, I finally realized it will work if I upload the pics to GOOGLE PHOTOS instead of GOOGLE DRIVE. Then I can right-click on the pic, copy the address, paste it in, and it works beautifully.
In backend i created endpoint for showing images. Laravel code looks like:
public function getImage($name)
{
return response()->file(base_path() . '/resources/img/' . $name . '.png');
}
Then in my html email template i created div with background-image.
<div style='background: url("https://mysite1.com/api/v1/get_image/logo")'></div>
And it's works for me.
I tried another image from internet which url starts https://
it worked on gmail and outlook.
get your images from domain which has SSL.
For me, the problem was using images name as equity investments.png . I switched them to equity_investments.png and it worked.
Not working :-
<img src="https://xxxxxxx.com/webinar_images/equity investments.png" alt="" />
Working :-
<img src="https://xxxxxx.com/webinar_images/equity_investments.png" alt="" />
I tried all the suggestions this thread (setting width, height, title, full url, etc). The final fix for me was switching from SVG to PNG did the trick for me.
I then tried removing all the other extra decorators (title, display block), and it still worked as long as I left the image type as PNG. So, PNG seems to be the only required change.