New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 124 users

Issue metadata

Status: Fixed
Closed: Dec 2014
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Compat

Sign in to add a comment

Broken/missing/not found images should display ALT text

Reported by, Sep 3 2008

Issue description

Product Version      : <>
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 3:
    Firefox 3: OK
         IE 7: OK

What steps will reproduce the problem?
1. Browsing vBulleting forums

What is the expected result?
Displaying TAG words

What happens instead?
Does not display tagwords on all vbulletin forum pages, just "missing 
Please provide any additional information below. Attach a screenshot if 

Labels: -area-unknown Area-Misc

Comment 2 by, Nov 11 2008

Taking these to triage.

Comment 3 by, Nov 12 2008

Status: Invalid
I can see the broken image link for 
and when I tried to access it with FF3/IE7/Safari they all gave the same result.  The 
webserver is returning a 404 for those images.
Well, yes when I right click on the tag to open an image it shows me 404 with all 
browsers as well.
But no user will right click on the tag to open it as an image and if you llok with 
IE or Firefox you will ACTUALLY SEE ALL TAGS, with Chrome you just see that "missing 
image" symbol.
I just tried it again and all tags are displaying properly in IE and Firefox but not 
in Chrome. 
I have no idea how to generate a screen shot with Vista, otherwise I would attach it. 
That's not the point!
In IE and Firefox you can see all tags displayed correctly, Chrome shows that missing 
image symbol.

Comment 6 by, Nov 12 2008

[Confirmed] - Very valid and known Safari issue!

Regarding other browsers:
   Safari 3 - FAIL, Opera 9 - OK, Firefox 3 - OK, IE 7 - OK (and Chrome - FAIL)

Problem only for Safari and Chrome.

This is an already known Safari problem and is exactly because Safari and Chrome are 
not automatically showing the ALT text when the image is missing.  See:

[Upstream] ?
If this is a known issue why Jon just simply closed that issue and marked it as 
Invalid without researching it further? 

Jon, could you please re-open it. 

This is a valid Chrome bug and quiet important. 

Just think about how many million of users are browsing vbulletin forums and 
therefore will prefer not to browse with chrome.

Comment 8 by, Nov 12 2008

I meant it is a known issue in Safari circles.

Now, hopefully, it will also be known to Jon and the Chrome dev team as well.

Jon, please re-open or re-status the bug as Upstream and label it Reported-to-WebKit 
or whatever label.
Labels: -Area-Misc Area-WebKit
Status: Upstream
Summary: Broken images should display ALT text
This is a valid bug, and the code that needs to be fixed is in WebKit. 
 Issue 5846  has been merged into this issue.
 Issue 8189  has been merged into this issue.

Comment 12 by, Jul 14 2009

 Issue 16734  has been merged into this issue.

Comment 13 by, Jul 20 2009

Labels: Mstone-4
We need someone to take this WebKit bug.  So far no one has claimed it.
Found this page very useful,
Explaining the real syntax of tags Alt and Title.
I changfed my alt-texts to title tag instead, and works fine with Chrome.

Comment 15 by, Sep 24 2009

Status: Untriaged
Karen will be handling WebKit issues.  I am moving myself off of being an 
owner of this issue.  She may want to handle these differently so I am 
setting the status as untriaged.

Comment 16 by, Sep 29 2009

Status: WontFix
Use title attribute.

Comment 17 Deleted

Comment 18 by, Sep 29 2009

The alt attribute is to show an ALTernative text if the image is broken...
The title attribute is to show a short description of the image

So the alt-attribute should be supported and the text should be shown -at the same 
place where normally the image would be- if the image cannot be loaded...

Comment 19 by, Oct 21 2009

Quote from w3schools:
"The required alt attribute specifies an alternate text for an image, if the image 
cannot be displayed.

The alt attribute provides alternative information for an image if a user for some 
reason cannot view it (because of slow connection, an error in the src attribute, or 
if the user uses a screen reader).

Note: Internet Explorer displays the value of the alt attribute as a tooltip when 
mousing over the img element. This is NOT the correct behavior, according to the HTML 
specification. All other browsers are following the specification, and will only 
display the alt text if the image cannot be displayed.

Tip: If you want to create a tooltip for an image, use the title attribute."

This shows you the difference between alt and title! 
That is why alt should be supported. Please reopen this bug!

Comment 20 by, Nov 8 2009

 Issue 27082  has been merged into this issue.
Please re-open this.

The reason given for closing this case was "Use title attribute."
Using (or not using) the title attribute does not (and should not) affect the display 
of a misdirected <img> element.

To demonstrate, create a file called test.html which contains the following element: 
<img src="C:\DoesNotExist.jpg" alt="alternate" title="title" />
As pointed out in comment 19, the correct behavior in this case would be to display 
the word "alternate" in place of the missing image.
Instead, Chrome displays the "missing image" icon with no text at all.
Note that the width of the box where the image would go is determined by the length 
of the alt text.
This means that the alt text is being used somewhere, but it's just not being 
This bothers me very much when viewing IM conversation logs. Please re-open and fix 
this bug. When I need to view conversation logs that have much broken images I had to 
open it in Firefox.

Comment 25 by, Jun 27 2010

 Issue 29967  has been merged into this issue.

Comment 26 by, Jun 27 2010

 Issue 34230  has been merged into this issue.

Comment 27 by, Jun 27 2010

Labels: -Mstone-4 Area-Compat-Web Mstone-X kglater
Status: ExternalDependency
Summary: Broken/missing/not found images should display ALT text
As mentioned, this is upstream WebKit bug:

Comment 28 by, Jul 30 2010

Even though this is an upstream WebKit bug, it doesn't mean it can't be patched in Chromium.  It's been a bug in WebKit for nearly 5 years.  Omniweb has patched it in their code and they are WebKit based.

I think if it's going to be fixed, you're going to have to do it yourself because there's no view in sight of WebKit ever fixing it themselves.  As a browser in the front lines of taking market share, I don't think relying on WebKit to fix the issue is a viable option here.

Comment 29 by, Jul 30 2010

Also, like FF, the alt text should be displayed with whatever formating text would normally be displayed with in the same location.  So you could use CSS like so:
img {
And the alt text would display as such.

Comment 30 by, Aug 18 2010

Umm... actually, I just realized that chrome does show the alt text... heh, it seems another issue obscures it.

If you set a width and height on an image that's big enough, the alt text will show.  min-width and min-height are good enough to use.  The problem is, the image alt text will not wrap at all and that little image placeholder icon actually knocks the alt text somewhere else so it doesn't show if it's not much taller than that icon.

It actually does obey any text styling you have listed on the img. so img { font-size:20px; } works, but makes it so the box needs to be even bigger.

Perhaps another bug should be filed as it seems the issue has been a side effect of something slightly different.
Thats insane that this bug is from 5 years ago and WebKit still haven't fixed it. Firefox's and I assume most other browsers way of rendering this is the best approach (treating the contents as an inline element with full style support). Its perfect for situations where you're using images for custom font use, if the image doesn't exist you can make it fall back to something that looks relatively similar. At the moment you get an ugly icon which tells you nothing.
 Issue 63738  has been merged into this issue.
Seriously, please fix this now. It has been two years.

As a web designer, I need people to be able to read the "alt" text in case the images break unexpectedly during server maintenance. Otherwise, users will just see blankness and if the image is an important button like "Join Now!" it will be completely USELESS, requiring me to add more text to the page, making it look redundant. 

I'm pretty surprised it's been two years and this hasn't been dealt with yet. A little disappointed.
Agree with last comment, please fix it. It's Chrome's shame.

Comment 35 by, Jan 29 2011

Webkit needs to fix it.  A link to the webkit bug was already posted here.  They don't seem to see any merit in it at all and haven't even assigned it to anyone.  It's been sitting there since 2005, 6 years.

Doesn't the chromium team ever push bug fixes back up to webkit?  Or can't they push for them to fix certain bugs at all?

Comment 36 by, Mar 22 2011

I have version 10.0.648.151 and it's still not fixed. I wonder if Acid3 would include this in the test if Google would finally fix this defect.
Labels: -Area-Compat-Web bulkmove Area-Compat

Comment 38 by Deleted ...@, Apr 13 2011

Come on people! This has been a known bug for six years! What's the point in web standards if browser vendors just ignore them? Why do we spend hours optimising our code for situations like this, only to find it's all a complete waste of time? Such a basic thing, displaying an alt text. It would take a second to fix. Why has it languished broken for six years? This is madness. Somebody, get this sorted, come on!

Comment 39 Deleted

Comment 40 Deleted

I agree with aliblack.
I can understand that many bugs aren't easy to fix, but continually failing to display alt text is unreasonable for a company like Google.
Both Google and the Webkit folks have been alternately putting this off and claiming that it's not a problem.
Yes, this is technically a Webkit issue, but you are using Webkit and it's making you look bad. With all the other things that Google can do, this should not be a problem to either fix on your end, or encourage/help Webkit to fix.

Comment 42 by, Apr 13 2011

There's nothing chromium can do, why are you complaining here?  Have you even bothered reading any of the comments before bothering to post?
Go somewhere it will be useful, like the webkit bug, which has been linked to here, if you read the comments.


I've read all the comments and I still don't see the reason why nobody at Google or otherwise is able to claim this bug. All I see is people saying it's Webkit's responsibility, which I find weird considering the seemingly small effort needed to fix this. If I wasn't so swamped right now, I bet even I'd be able to dig into Webkit's code and fix it!

I understand people at Google/Webkit are probably also swamped, but they have all the insight into the code, and it should take a much smaller amount of time for them to fix it.

Even though I can relate to the fact that people can get sick of nagging, telling people to "go somewhere [else]" is _quite_ unhelpful and not very nice. I mean let's be honest, this bug is pathetic. It's been around for 6 years, so it's like... "wtf".

If the bug has been sitting at Webkit since 2005, I think it's fairly okay to assume they're not interested in fixing it, which makes people want to try somewhere more trusty; and they make that place out to be Google. :P

Comment 44 by, Apr 13 2011

If you look at the comments on the webkit bug, notice that I'm "Adam" and have been 'nagging' them.

I mentioned in comment 28 that omniweb fixed it in their webkit based browser, and in comment 30 the actual nature of the bug.

If you want it fixed, nag the right people.  chromium seems set on keeping it as an external dependency issue.  So go sign up for bugs.webkit and get it attention.
Chromium seems set on keeping it as an external dependency and Webkit seems set on keeping it unresolved. :|

Comment 46 by, Apr 13 2011

Actually this issue does not occur. If you try to set an unexisting images sizes larger the text will show. The alt text isn't displayed because the broken image has some kind of borders and hides the text. Try to enforce a larger image by specifing it's size and the text will become visible.
That's not the issue now, the issue is that the broken image shouldn't even be there.

Having to force the box size shouldn't be necessary. The current behavior is very much an issue!

Comment 48 by, Apr 13 2011

Well, the broken image should be shown if there is no alt text.

If there is alt text, that should be shown instead, perhaps being preceded with an inline broken image so one can still be aware that an image was supposed to be there.
The alt text should be stylable as well.

Comment 49 by, Apr 13 2011

Instead of complaining you could also create a patch yourselves. Your whining doesn't help anyone. All you managed to do is bringing the number of stars back to 51.

@karen, please lock this issue with restrict-addissuecomment-commit
Complaining? We're trying to drive this bug towards fixing! Pardon us if we're not experts on where that should be conducted if not on the bug report itself. :D (:P)

Regarding the broken image:

"Except where otherwise specified, the alt attribute must be specified and its value must not be empty [...]"


"The image given by the src attribute is the embedded content, and the value of the alt attribute is the img element's fallback content."


"Some embedded content elements can have fallback content: content that is to be used when the external resource cannot be used (e.g. because it is of an unsupported format). The element definitions state what the fallback is, if any."


I'm not so sure the 'broken-image' image should even be there at all. Seems more like it's a relic from old behavior if anything.
Chromium developers be advised; I have a blog post scheduled for tomorrow afternoon, to mock you (but mostly WebKit) for not having patched this like OmniGroup did 3 years ago. It's just the kind of absurd pedantry that we don't have time for anymore. Lets get this done.

Comment 52 Deleted

Comment 53 Deleted

Comment 54 Deleted

Comment 55 Deleted

Comment 56 by Deleted ...@, May 8 2011

Aiaiaiai....I read the comments....i have nothing else to say then, shame on you chronium/google, very dissapointing.
When will it be fixed?
Needs to be fixed.  I don't care who does it.

Comment 59 by, Jan 2 2012

Agree it needs to be fixed, a simple bug that even Netscape 10+ years ago supported nicely.

Comment 60 by Deleted ...@, Jan 27 2012

It's not just for when the image isn't supported... for branding purposes on a job site search engine for instance the alt tag would show the text of the companies name automatically for instance if a branding image hasn't been put in the image repository yet. 

Comment 61 Deleted

Comment 62 by Deleted ...@, Jan 27 2012

"Well, the broken image should be shown if there is no alt text.

If there is alt text, that should be shown instead, perhaps being preceded with an inline broken image so one can still be aware that an image was supposed to be there.
The alt text should be stylable as well."

 I actually like firefoxs' solution that only shows the alt text, prettier and more elegant. having outside customers see the broken image link is ugly and not customer friendly. 

Comment 63 by, Feb 25 2012

 Issue 114145  has been merged into this issue.

Comment 64 by, Feb 26 2012

Please make sure ALT codes show up.

Case in point:
My makes extensive use of
images from sites prohibited in China.

I was forced to shorten the ALT codes to make sure they fit within
Chromium's boxes.

Else Chinese readers will think it is me who wrote such an irresponsible
web page with no ALT codes.

Thankfully at least Chromium still shows the rectangle, vs. certain
other browsers .

Comment 65 by Deleted ...@, Mar 2 2012

+1, for all the good it'll do. This bug really makes Chrome look bad (even if it's Webkit's fault). Firefox does it correctly and seamlessly. 
Seems like this is a layout issue in WebKit: alt text does not have any overflow properties beyond "hiding" the alt text if there is any overflow. Even clipping would work better. This issue occurs when an image width has been manually set and the text does not fit into the line box. Mozilla has a moz-broken selector which could be used with replaced and generated content. That may be how we eventually get this addressed in WebKit-- by adopting additional CSS conventions.

Comment 67 by, Jun 12 2012

 Issue 132256  has been merged into this issue.

Comment 68 by, Sep 22 2012

<p>Image Alt Test<br>
<img src="missing.jpg" alt="Image is not found.. Showing Alt Text">

Alt Text is not painted. It just shows broken image. Please help to fix it..

Screenshot attached.
96.0 KB View Download
The bug also trigger when the img refers an existing image file that Chrome does not handle, like for instance old XBM files.

Comment 70 by Deleted ...@, Nov 27 2012

Please fix it. It was since 4 years. Hello Google, please! :)

Comment 71 by, Nov 27 2012

STOP! This issue is not a bug. Please note that if the broken image is expanded or is big enough the ALT text is displayed. So please close this issue. 
No, to show ALT text in Chrome, the space must be more than enough, that's a bug.
More than 4 years to display image alt tags?
Project Member

Comment 74 by, Mar 10 2013

Labels: -Type-Bug -Area-WebKit -Area-Compat Type-Compat Cr-Content
Project Member

Comment 75 by, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Wow, will you let it complete 10 years?
I've reported it as #244357 because I haven't find this in my search before.

Comment 77 by, Jul 17 2013

Just to be clear, this issue is related to a confirmed bug in WEBKIT, which can be tracked here:

Feel free to add input and follow progress on the fix at that link, as this will likely not be addressed directly here or by the chromium team at all (unless it's done in Blink).
Blink is a fork of WebKit, this puts the responsibility completely in Chromium project now ("borrowing" the code from WebKit project as long as it fits or not, regardless, Chromium isn't tied to WebKit anymore).

Comment 79 by, Jul 17 2013

 Issue 244357  has been merged into this issue.

Comment 80 by, Jul 17 2013

You have a point, Rafael, which is why I mentioned Blink. On April 5 this issue was labeled for Blink, but the status wasn't changed from "ExternalDependency" (and there still isn't an owner). Still, I have hope that this is the year the bug will be fixed..

Comment 81 by, Jul 17 2013

Status: Available

Comment 82 by, Jul 17 2013

Thanks for updating the issue, though (getting off-topic, sorry) it looks like quite a few other issues have the same probably-stale "ExternalDependancy" status since the bulk move of issues from WebKit to Blink:

Sep 3, 2008 this was reported. I want to second comment #30 as a work-around, and a hint at the underlying issue. Alt text is pretty important, and it's shameful that 6 years later this still isn't addressed.

Comment 84 by Deleted ...@, Jul 22 2014

Any update for this issue

Comment 85 by, Jul 22 2014

Looks like someone took the advice of comment #30 and filed a new issue that properly describes the bug--see  Issue 157207 .

Everyone, feel free to star it so it can get more attention.
lol, devs cant fix this bug for 6years, srsly? #fail

Comment 88 by, Dec 13 2014

Status: Fixed
Should be fixed by

Please try it out in a Canary build ( and let me know.

Comment 89 by, Dec 13 2014


Comment 90 by, Dec 13 2014

 Issue 440733  has been merged into this issue.
Works for me. Thanks
 Issue 157207  has been merged into this issue.
I can also verify it works in Version 42.0.2310.0.

Comment 94 by, Sep 15 2015

 Issue 247273  has been merged into this issue.

Sign in to add a comment