HTML image not showing in Gmail - html

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.

Related

Outlook adding destination URL in square brackets after hyperlink in HTML e-mail

Bit of a head scratcher here, and I'm still waiting on some details.
The client reported that in Outlook, they are seeing the link in square brackets after the A tag. This apparently just started with the most recent round of e-mails I did for them, but the link code has not changed.
Here is an example of a link :
<p style='margin-bottom:20px !important;' >
Visit MyBlue to log on or register today.
</p>
Here is an image of what they are seeing :
http://rweststaging.com/webmd_emails/example/example.png
I've tested in Litmus, and sent out test e-mails through MailChimp, and I'm not seeing that on any of the outlook versions.
I thought it might be some setting on their particular Outlook install, but they reported only seeing that happen on this particular group of e-mails.

try to add https:// to link in <a> html tag

I had the same problem but in my case part of the url was written with "\", I changed that to "/" and problem was solved-

How to change the behaviour of the smiley feature in CKEditor

We use CKEditor to construct emails. Now, when activating the smiley button, the smileys are actually added as
<img alt="smiley" src="<app>/script/webeditor/ckeditor/plugins/smiley/images/regular_smile.png" />
Of course, in an email we can not refer to an internal application URL. So, what are the options here?
Gmail solves this by adding the smileys as inline images of the email
Hotmail solves this by referring to images on a public location
I found documentation about 'BBCode-mode' of the ckeditor, which would add the smiley as [:-)] and let the application which shows the bbcode decide which picture to use.
there are HTML codes to show smileys, but browser support seems to be poor.
My question: which option to use? Are there already plugins available that handle one of those options? Ideally, something like BBCode should be available as valid HTML, supported by all browsers, maybe there is?

I can tell you how to do it with a fixed location for the images (like Hotmail). You have to set a config property like this:
config.smiley_path = "http://www.example.com/images/";
This should render
src="http://www.example.com/images/regular_smile.png"

How do I stop Gmail from stripping the values out of URLs?

I recently learned that webmail clients like Gmail will do alterations on HTML emails, for example adding target="_blank" to <a> tags.
I've also discovered that other alterations happen as well. When I send an HTML email to Gmail (and possibly other web mail clients) from my PHP script, variable values included in the URL of any links are being stripped out. So, for example, this is the value I'm setting in my PHP code:
$mailContent = '<p><a target="_blank" href="https://example.com/confirmation.html?verification=x1x1x1x1x1x1x1x&email=yyyy#email.com">click here to go to the web site and activate your account!</a></p>';
But when the email is received in Gmail, the HTML code comes out like this:
<p><a target="_blank" href="https://example.com/confirmation.html?verification=&email=">click here to go to the web site and activate your account!</a></p>
The values x1x1x1x1x1x1x1x and yyyy#email.com have been stripped out from within the <a> tag.
How do I protect the values of the variables that I want to pass to the URL so that Gmail won't remove them?

Click View original/source on the message in Gmail to see if the URLs looks like they should then. If so you know that the problem is how Gmail is formatting the message for your viewing. If it's mutilated even in the source I was wondering if there's anything in your webpage/php/CMS (do you use one) that changes the code.
You should try URL-encoding as #Crisp said. Here's the W3 reference.

Emailing in html uses Quoted-printable Encoding. The problem with your $mailContent is that the "=" must be represented by =3D
Try adding this:
$mailContent = quoted_printable_encode($mailContent);

This may not be the perfect answer, but if your application allows for it, I have used URL shorteners a number of times.
http://goo.gl/ is my preferred because the API is super easy to implement and google is very fast. I have a function in a class and I just run my url through it and send the return wherever I need it to be.

Another non-perfect answer here but, my problem was that I was including an http url in the html body and apparently is not valid so I changed them to https. This was on a dev environment so no problem on production.
Here is more info about this:
Any URL's in the body of the mail which lead to insecure sites may also need to be removed. Use https://transparencyreport.google.com/safe-browsing/search to validate these links.. All links should be correctly prefixed with "https". https://en.wikipedia.org/wiki/HTTPS Google seem to be rejecting "http". Sometimes, but not always, removing links from any signature can help.

Failover for email images

I am developing a system that sends emails out to recipients who may read the email from a public access point, or a "closed" access point (that can't see the internet). My emails, which are sent in HTML format, might have images embedded. The images are pre-defined and live in known locations. Naturally, email read from the (public) internet can't load images hosted in the (private) closed network; email read from the closed network can't load images from the internet.
For now, during email generation we are determining from the recipient's email address whether we should set the img src to be the public or private path. I'd love to find a native HTML technique that could tell the email client "try this public path to the image, and if it doesn't load failover to this private path". My understanding is that email clients are almost always expected to strip-out JavaScript, so ECMA won't be a part of this solution. Sadly.
Attempt 1
I tried setting the src to be the public path to the image, and set the background-image style attribute to be the private path to the image:
<img src="path/to/public/my_image.jpg" style="background-image:url('path/to/private/my_image.jpg');" ..etc.. />
That works great in a browser (especially if height/width attributes are set), but Outlook (2007) does not support background-image. So, no joy.
Attempt 2
I tried creating a table with a background image:
<table background="path/to/private/my_image.jpg">
<tr>
<td>
<img src="path/to/public/my_image.jpg" />
</td>
</tr>
</table>
Outlook didn't go for that either.
Attempt 3
In the spirit of "it just might be crazy enough to work", I tried supplying two src attributes to an image:
<img src="path/to/public/my_image.jpg" src="path/to/private/my_image.jpg" ..etc.. />
That didn't work anywhere; only the first src would get used to try to load the image.

If your logic is made on the server, I think you'd be better off linking to a script that generates / serves the correct image, instead of an image directly?
Something like:
<img src="http://www.example.com/path/to/script/image.php?email=info#example.com&name=example-image-1" />
image.php would then base some logic on the parameters given. These could be the email of the recipient (which could detail their access rights) and perhaps a name for the image (so that you know which image to serve in this position).
You would then need to serve image.php as the correct mime type of an image, so that the email client can render it correctly.
This would be far more advantageous over trying to use hacks in the email itself.
Hope this helps?
Mikey.
PS - Remember to serve absolute URL's in HTML emails. Relative images won't work.

Why not embed the images as attachments? You can specify the src attribute of the img tags as "cid:xyz" where "xyz" if the "Content-id" MIME attribute of the image attachment.

What's the valid way to include an image with no src?

I have an image that I will dynamically populate with a src later with javascript but for ease I want the image tag to exist at pageload but just not display anything. I know <img src='' /> is invalid so what's the best way to do this?

Another option is to embed a blank image. Any image that suits your purpose will do, but the following example encodes a GIF that is only 26 bytes - from http://probablyprogramming.com/2009/03/15/the-tiniest-gif-ever
<img src="data:image/gif;base64,R0lGODlhAQABAAD/ACwAAAAAAQABAAACADs=" width="0" height="0" alt="" />
Edit based on comment below:
Of course, you must consider your browser support requirements. No support for IE7 or less is notable. http://caniuse.com/datauri

While there is no valid way to omit an image's source, there are sources which won't cause server hits. I recently had a similar issue with iframes and determined //:0 to be the best option. No, really!
Starting with // (omitting the protocol) causes the protocol of the current page to be used, preventing "insecure content" warnings in HTTPS pages. Skipping the host name isn't necessary, but makes it shorter. Finally, a port of :0 ensures that a server request can't be made (it isn't a valid port, according to the spec).
This is the only URL which I found caused no server hits or error messages in any browser. The usual choice — javascript:void(0) — will cause an "insecure content" warning in IE7 if used on a page served via HTTPS. Any other port caused an attempted server connection, even for invalid addresses. (Some browsers would simply make the invalid request and wait for them to time out.)
This was tested in Chrome, Safari 5, FF 3.6, and IE 6/7/8, but I would expect it to work in any browser, as it should be the network layer which kills any attempted request.

These days IMHO the best short, sane & valid way for an empty img src is like this:
<img src="data:," alt>
or
<img src="data:," alt="Alternative Text">
The second example displays "Alternative Text" (plus broken-image-icon in Chrome and IE).
"data:," is a valid URI. An empty media-type defaults to text/plain. So it represents an empty text file and is equivalent to "data:text/plain,"
OT: All browsers understand plain alt. You can omit ="" , it's implicit per HTML spec.

I recommend dynamically adding the elements, and if using jQuery or other JavaScript library, it is quite simple:
http://api.jquery.com/appendTo/
http://api.jquery.com/prependTo/
http://api.jquery.com/html/
also look at prepend and append. Otherwise if you have an image tag like that, and you want to make it validate, then you might consider using a dummy image, such as a 1px transparent gif or png.

Use a truly blank, valid and highly compatible SVG, based on this article:
src="data:image/svg+xml;charset=utf8,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%3E%3C/svg%3E"
It will default in size to 300x150px as any SVG does, but you can work with that in your img element default styles, as you would possibly need in any case in the practical implementation.

I haven't done this in a while, but I had to go through this same thing once.
<img src="about:blank" alt="" />
Is my favorite - the //:0 one implies that you'll try to make an HTTP/HTTPS connection to the origin server on port zero (the tcpmux port?) - which is probably harmless, but I'd rather not do anyways. Heck, the browser may see the port zero and not even send a request. But I'd still rather it not be specified that way when that's probably not what you mean.
Anyways, the rendering of about:blank is actually very fast in all browsers that I tested. I just threw it into the W3C validator and it didn't complain, so it might even be valid.
Edit: Don't do that; it doesn't work on all browsers (it will show a 'broken image' icon as pointed out in the comments for this answer). Use the <img src='data:... solution below. Or if you don't care about validity, but still want to avoid superfluous requests to your server, you can do <img alt="" /> with no src attribute. But that is INVALID HTML so pick that carefully.
Test Page showing a whole bunch of different methods: http://desk.nu/blank_image.php - served with all kinds of different doctypes and content-types. - as mentioned in the comments below, use Mark Ormston's new test page at: http://memso.com/Test/BlankImage.html

As written in comments, this method is wrong.
I didn't find this answer before, but acording to W3 Specs valid empty src tag would be an anchor link #.
Example: src="#", src="#empty"
Page validates successfully and no extra request are made.

I found that simply setting the src to an empty string and adding a rule to your CSS to hide the broken image icon works just fine.
[src=''] {
visibility: hidden;
}

if you keep src attribute empty browser will sent request to current page url
always add 1*1 transparent img in src attribute if dont want any url
src="data:image/gif;base64,R0lGODlhAQABAAAAACwAAAAAAQABAAA="

I've found that using:
<img src="file://null">
will not make a request and validates correctly.
The browsers will simply block the access to the local file system.
But there might be an error displayed in console log in Chrome for example:
Not allowed to load local resource: file://null/

Building off of Ben Blank's answer, the only way that I got this to validate in the w3 validator was like so:
<img src="/./.:0" alt="">`

I personally use an about:blank src and deal with the broken image icon by setting the opacity of the img element to 0.

<img src="invis.gif" />
Where invis.gif is a single pixel transparent gif. This won't break in future browser versions and has been working in legacy browsers since the '90s.
png should work too but in my tests, the gif was 43 bytes and the png was 167 bytes so the gif won.
p.s. don't forget an alt tag, validators like them too.

I know this is perhaps not the solution you are looking for, but it may help to show the user the size of the image before hand. Again, I don't fully understand the end goal but this site might help: https://via.placeholder.com
It's stupid easy to use and allows to show the empty image with the needed size.
Again, I understand you did not want to show anything, but this might be an elegant solution as well.
<img src="https://via.placeholder.com/300" style='width: 100%;' />

Simply, Like this:
<img id="give_me_src"/>