Wikipedia talk:Image use policy

Watermark exception for AI

As suggested by Anomie I'll start a discussion about this.
There is currently an RfC on Commons about adding an in-image indication of inauthenticity to certain categories of images. If this RfC passes that will in many cases result in an "AI" watermark. How do you feel about an exception to WP:WATERMARK for this? — Alexis Jazz (talk or ping me) 01:43, 26 June 2026 (UTC)

• Comment: Sometimes the watermark may be different. c:File:Alex Pretti AI comparison.jpg for example also includes an "in-image indication of inauthenticity", and a bar that is added to the top or bottom of the image would be possible as well and might be desirable if the image data itself must remain fully intact. English Wikipedia already disallows most AI images, and many of the few that are allowed will not be affected by the RfC because both notable and unrealistic images are mostly exempt. For AI art only File:Sunset Valley (FLUX 1.1 Pro Raw).webp would be affected. AI-upscaled images on Image scaling#Deep convolutional neural networks would be affected. If DLSS had images it would be affected. In that particular case, assuming it's not photorealistic, a watermark that says "DLSS" would be acceptable as that would be appropriate for the target audience. In my opinion, that could actually be helpful when flicking through comparison images in MediaViewer. Currently that article has no images so this is moot for now. For AI slop, File:AI-generated veteran birthday sign image.png could be affected. That's potentially another citogenesis incident prompted by Belbury (the first one being shrimp Jesus), if there are now sources for that image it may be exempt. — Alexis Jazz (talk or ping me) 01:43, 26 June 2026 (UTC)
• Yes, I think a watermark exception for AI is good. I really like what the NYTimes does, which is add a big red bar across the image and "AI" . I'd almost go so far as to require it, but I think we can visit that can of worms at a later date. CaptainEek ^{Edits Ho Cap'n!}⚓ 05:11, 26 June 2026 (UTC)

I think WP:NDT may be more relevant, but since this is for educational purpose (rather than just trying to protect readers) I think it's good to IAR here Kowal2701 (talk, contribs) 16:00, 26 June 2026 (UTC)

If we are using AI generated image for the purposes of illustrating what AI can do, and that engine spits out a watermark, and there is no other way to use a different image generator that does not include a watermark, then yes, this is a reasonable exception. Masem (t) 17:14, 26 June 2026 (UTC)

This isn't about AI content watermarking, or even visible ones, added at generation; it's about us deliberately adding them. —Cryptic 18:47, 26 June 2026 (UTC)

More specifically, it's about Commons proposing to require watermarks be added to various types of AI-generated images. Anomie⚔ 22:15, 26 June 2026 (UTC)

Currently, our use of AI-generated images is already very restricted. In the rare cases where they can be used, even though they can often already be inferred from context and captions (e.g. as explicit examples of AI content), an explicit indicator like what the New York Times does would be pretty helpful. What I'm having in mind is mostly reuse: our images might be clearly indicated as AI in context, but reusers (such as Google Search) often take them away from this context, and having something baked in the image prevents confusion from spreading. Chaotic Enby (in solidarity · talk · contribs) 18:12, 26 June 2026 (UTC)

The reuser issue is a good point, especially for articles like AI-generated content in American politics where we reproduce deliberately deceptive content as examples of a phenomenon. -- LWG ^{talk (VOPOV)} 15:10, 27 June 2026 (UTC)

No. Watermarking is the worst way to accomplish this possible. PARAKANYAA (talk) 01:48, 27 June 2026 (UTC)

How is a watermark the worst way to communicate that an image is generated? fifteen thousand two hundred twenty four (talk) 03:31, 27 June 2026 (UTC)

Because it makes the image entirely useless? PARAKANYAA (talk) 04:17, 27 June 2026 (UTC)

That's an interesting perspective, but not one I understand. An image depicting foo still depicts foo even if it has a watermark indicating it's an AI rendition of foo. If anything the addition of a watermark conveys more relevant information to a viewer (this is not a natural image of foo), not less. fifteen thousand two hundred twenty four (talk) 04:27, 27 June 2026 (UTC)

It becomes useless for depicting it, even if it does still depict it, due to quality reasons. If you think a massive watermark over the images at AI art would make anything any clearer I'm not sure what to say. PARAKANYAA (talk) 14:14, 27 June 2026 (UTC)

Since it looks like Commons is about to add watermarks to AI images whether we like it or not, the real question for articles like AI art isn't whether watermarks would make the images better, it's whether we should permit the use of watermarked images from commons if the raw images aren't available. -- LWG ^{talk (VOPOV)} 14:55, 27 June 2026 (UTC)

Yes, and what I'm saying is that no, we shouldn't. PARAKANYAA (talk) 15:35, 27 June 2026 (UTC)

• The WP:WATERMARK policy was written before AI images and doesn't really fit what they are. The policy is concerned with image modifications "that would hamper their free use". A watermark on an AI image does not do this. A watermark noting AI generation is not an assertion of copyright or ownership. Any watermark can also be removed by another AI program, in a way that would not work well for something like photographs, as there is no underlying image to recover. Depending on the design of the watermark, any AI image where it covered an important element could be reworked to incorporate the watermark positioning if needed. We may want a clear exemption for AI images being talked about for their own merits, such as external examples that get commentary in the article. A lot depends on what the watermark might be. CMD (talk) 16:37, 30 June 2026 (UTC)

Talk:Vietnam War#Collage is missing Phan Thi Kim Phuc

Please see the subject discussion regarding the lead image for the article. Cinderella157 (talk) 00:10, 5 July 2026 (UTC)

Confused wording in WP:IMGSIZELEAD?

This page currently states that The lead image in an infobox should generally not exceed the default size of the infobox. Therefore, it should be no wider than upright=0.9 (equivalent to 228px for most infoboxes, which use the default width of 22em). For logged-out users on desktop using the "Standard" text size (at least when testing on my machine), the infobox is 310px in width and the image is 250px (80% of the width); with the "Small" text size, the measurements are 271px and 250px (92% of the width). I think the wording used in this guidance might be a little confused: the first sentence refers to avoiding making the image so wide that it forces the infobox to also be wider, but as my cases show a size of "upright=0.9" is not required to do this, nor is this standard respected by default layout settings. I propose that we remove or otherwise tweak the second sentence. — Goszei (talk) 19:59, 29 July 2026 (UTC)

Is this regarding a specific custom info box? Module:Infobox/styles.css = width: 22em ..... BUT wondering if we need to update our guideline here ...At Module:InfoboxImage I do see 250px added in 2025... That seems to have caused many discussions at Module talk:InfoboxImage. Moxy🍁 23:00, 29 July 2026 (UTC)

It seems the concern is that "22em" depends on the font size, and different skins have different default font sizes. In Monobook it works out to about 246px, in Vector to about 271px, and in Vector 2022 it depends on the font size selection with "Standard" giving about 310px. In all cases these are based on the browser's default font size, and may vary if that has been changed too. The current recommendation for "upright=0.9" with the standard image preference size of 250px results in a 230px image (rounding up from 225px), which fits comfortably inside the Monobook table cell (which is 231px thanks to padding and borders) but leaves some room in Vector 2022 (table cell 294px at "Standard" size). OTOH, the extra whitespace may well fit the aesthetic of Vector 2022, which uses excess whitespace in many other places too. Anomie⚔ 13:42, 30 July 2026 (UTC)

This may go back to when Monobook was the default display. In vector, "upright=1.2" is the maximum that does not impinge on the default infobox size. An update is in order. Cinderella157 (talk) 23:12, 29 July 2026 (UTC)

Where we getting this 300 pixel number from? 250 is what is set at Module:InfoboxImage after what seems to be a long discussion and our recent change in upsizing. Moxy🍁 23:33, 29 July 2026 (UTC)

Moxy, re your revert of my bold amendment , you would state that 300 is definitely not what the info box module says. I would refer to Northwest Indian War as an example, where 300px in Vector (2022) (the default display} does not impinge on the infobox (relative to the campaign box) but it does not quite fill the infobox. Nor does Vector (legacy) impinge on the infobox but it does fill it. There would appear to be a disjunction between what the module says and how it works in practice. Cinderella157 (talk) 23:50, 30 July 2026 (UTC)

Thats because Module:Infobox military conflict is set to upright=1.2 equivalent to 300px to override the norm.Moxy🍁 01:07, 31 July 2026 (UTC)

This .9 max is what we have used for years, and it works well. And remember, this is not a "guidance" or "guideline" article... this is policy! Usually I use .8 with .9 max, as is policy in the infobox. It starts to look more like a comic book with too large an image, even if the infobox will expand to encompass. upright=1.2 is gigantic. Screen sizes these days are actually getting smaller and smaller even though the pixels are sharper. Most laptops are 15" and 1920x1080 and tablets are about the same. A lot of cell phones are 1560x720. The infobox is for quick navigation and highlights of prose and really should not be displaying a gigantic image. Fyunck(click) (talk) 02:51, 30 July 2026 (UTC)

I think the concern is has this been updated since Wikipedia:Tech_news/Archive_13#Tech_News:_2025-16 Moxy🍁 03:54, 30 July 2026 (UTC)

That update did not include infoboxes. I had to override my preferences since that huge jump from 120 to 250 to 330. Suddenly images were half the page. Some have ignored this infobox policy and I think they have gotten out of hand. Remember it's .9 of the default and the default page image they keep making bigger so the .9 keeps getting bigger. If someone has their preferences set to 220 or 200 (like I did) and they don't override wikipedia, then wikipedia crushes the image to 120px and takes .9 of that. That caused a lot of grief with miniature images and a lot of editors have needed help unscrambling that. Fyunck(click) (talk) 05:36, 30 July 2026 (UTC)

Given the degree of variation we see in image size settings and how they show up on various displays/skins, isn't it better to avoid prescriptive rules in our policy? As I noted in my original post, the default size setting now (250px), which most users see, does not exceed 0.9 of the typical infobox width or only slightly does, and is nowhere near to making the typical infobox wider. — Goszei (talk) 06:06, 30 July 2026 (UTC)

But it does say "generally." It is not an ironclad policy. This allows for unusual pics that are better at a bigger size yet keeps pix mostly reasonable in size for an infobox. In 2024 infobox size was 270px yet we still used .9 as a normal max. Even our warning template at Template:Infobox too large says it should be .9 max as not all infoboxes are the same width. I don't know why we should change this. Fyunck(click) (talk) 07:05, 30 July 2026 (UTC)

IIRC the current phrasing is the result of a series of discussions late last year, cf. Wikipedia talk:Image use policy/Archive 16#practical status of largely landscape images on top of infoboxes. --Joy (talk) 14:26, 30 July 2026 (UTC)

That was some interesting back and forth argument reading. Thanks for that. I can see where landscape images, just like in the rest of prose, can sometimes be larger than their counterpoint portraits. Personally I would have them out of the infobox if at all possible... even above it... so the infobox can serve it's purpose. And I never liked multi-images in an infobox. It looks like points I'm making here have previously been brought to bear in October of '25. Fyunck(click) (talk) 17:16, 30 July 2026 (UTC)

If the recommendation is upright=0.9, then why aren't all infobox templates set to use 0.9 by default? The whole point of templates is standardization across articles... if we're not following the default 'by default', then we end up with a bunch of different infobox image widths across articles and the whole point of image size standards becomes moot. RachelTensions (talk) 14:40, 31 July 2026 (UTC)

Probably because the average reader doesn't really mind that relatively small difference. I mean, let's face it, people tolerate even two images squeezing the text, so tuning of a single image or box size on only one side of the text is minor in comparison. --Joy (talk) 15:06, 31 July 2026 (UTC)

Also the change in the default preference is fairly recent; before then the default size worked fine in infoboxes even in Monobook, and guidance here was about how much you were allowed to scale it up.

I tried digging into previous iterations of the guidance here, but as far as I can tell it has been fairly confused. For example, Special:Diff/873992288 in 2018 suggested that the default infobox width was 300px even though it seems to have been the same 22em (271px in the then-default Vector skin) back then, confirmed by spot-checking an arbitrary article in archive.org. Anomie⚔ 17:22, 31 July 2026 (UTC)

I agree with RachelTensions's point. I'm a bit confused about this default recommendation: why would we have to manually add "upright=0.9" to most infoboxes, instead of tailoring the infobox itself to set the images to 0.9? Nehme1499 (talk) 15:51, 2 August 2026 (UTC)

IMO, rather than applying upright=0.9 by default, maybe we should adjust the infobox stylesheet to be 24em wide in Monobook. That'd make the infobox about 268px by default (up from 246px), and the image table cell about 254px by default, letting a default-sized (250px) image fit. Timeless, Vector, and Vector 2022 all have larger base font sizes that give enough width for a 250px image already. Anomie⚔ 21:53, 2 August 2026 (UTC)

But why on earth would we want an even bigger image size in an infobox? Plus that would make all the wording wider in the infobox. Making a hard coded .9 is a better option, although since we already add the image file and caption for every infobox, adding an image_upright of .9 or .8 is no big deal. Fyunck(click) (talk) 19:44, 4 August 2026 (UTC)

Since the community decided the default image size should be bigger is why. Note it's only Monobook that needs the infobox widened. In Timeless, Vector, and Vector 2022, 22em is already large enough that a 250px image would not cause the infobox to expand. Anomie⚔ 22:14, 4 August 2026 (UTC)

But not in an infobox. Fyunck(click) (talk) 21:35, 6 August 2026 (UTC)

• Looking at this section in the policy, I see three key takeaways: 1) that the image in an infobox should not impinge on the default size of the infobox; 2) that a leadimage where there is no infobox should not exceed a certain size; and, 3) that we should use the upright feature to specify size rather than px. One issue is that not all infoboxes have the same default size (per Moxy) and hence the issue with my bold edit at the start of this discussion. A second issue is that the relevant numbers to use depend on the display preferences used. While editors may have different display preferences, our readers are unlikely to use anything but the default setting - eg Vector (2022). My observation is that the key takeaways in the policy do not require us to state what actual numbers should be used but we should be stating that the advice applies to how this is seen when using the default display setting. Numbers are a nice to have to guide editors and this is probably best done as a footnote. The key numbers are what upright setting to use. My view is that the other numbers that relate to this only confuse matters. They may be relevant to editors engaged module design but not more generally.
  If we are referring to scaling in an infobox, the parameter to use is | image_upright =? We should mention this. A direct link to Module:InfoboxImage is a bit confusing in that the template is invoked (eg {{#invoke:InfoboxImage|InfoboxImage|image=Abbey Rd Studios.jpg|upright=1.2}}). This is rarely seen in an infobox?
  When it comes to a stand-alone lead image (ie not in an infobox) is there a good reason why this should be larger than an image rendered using thumb? Specifying thumb as the preferred maximum size would simplify the guidance. Cinderella157 (talk) 01:50, 5 August 2026 (UTC)

GFDL and time zone

According to Wikipedia:Image use policy#GNU Free Documentation License, files licensed under GFDL only may not be uploaded if the file was licensed on 1 August 2021 or later. Which time zone is used for this? I noticed this user's uploads where GFDL-only files were uploaded up until the end of 31 July 2021 in the time zone where the photos were taken, but 31 July 2021 ended earlier in the GMT time zone, so some of the files were tagged for deletion five years after they were uploaded. The uploader seems to have followed local time while the person tagging for F3 deletion seems to have used GMT.

Pinging the uploader and those who tagged and deleted the files: User:Jonathunder User:Whpq User:Star walker User:CoconutOctopus --Stefan2 (talk) 10:26, 8 September 2026 (UTC)

The relevant RFC (Wikipedia:Village pump (proposals)/Archive 182#Restricting GFDL-licensed uploads) does not seem to have considered timezones. On the other hand, it does specifically say to look at when the work was licensed, and specifically not the date it was created or uploaded, which may complicate matters further. Anomie⚔ 12:04, 8 September 2026 (UTC)

If we interpret or clarify that licensing date needs to have proof, then the upload date is the license date for "own work", and other works would need to have a source that can be dated. -- Whpq (talk) 13:27, 8 September 2026 (UTC)

People can't license their work when they take the picture? Seems like you and others are making a bunch of assumptions here. Anomie⚔ 23:56, 8 September 2026 (UTC)

It was a suggestion to deal with the licensing date you brought up. We can just take it on faith that "own work" was licensed by the uploader some time before the cut-off date if they say so. -- Whpq (talk) 00:14, 9 September 2026 (UTC)

The licensing date part was probably copied from Commons (policy, RfC). Probably the idea was to still allow people to transfer files to Commons even if the file was uploaded to Wikipedia before the Commons cut-off date but not transferred to Commons until after that date? Maybe it makes less sense for Wikipedia, although it allows for copying files from other language-editions of Wikipedia if it was uploaded there after the Commons cut-off date but before English Wikipedia's cut-off date.

In theory, I could take a photograph today and then I sign a paper where it says that the photo is licensed under the GFDL, but I keep both the photograph and the signed paper secret for ten years. We require evidence of permission (WP:F11), so probably we would also want evidence of the licensing date. --Stefan2 (talk) 08:16, 12 September 2026 (UTC)

I would assume that GMT would be the applicable time zone. It is how we operate with other deadlines. -- Whpq (talk) 12:30, 8 September 2026 (UTC)

This, too, was my assumption when deleting. CoconutOctopus talk 12:38, 8 September 2026 (UTC)

I'd assume UTC, since that's system time. However, I think that rules such as this one should be interpreted in favor of the good-faith editor, and therefore if it's still July 31st Anywhere on Earth, I'd probably accept it. WhatamIdoing (talk) 03:51, 9 September 2026 (UTC)

Highly concur. These seem to have been good-faith contributions; we shouldn't delete them over an unspecified time zone. Pi.1415926535 (talk) 16:42, 9 September 2026 (UTC)

Maybe the policy could be amended to specify a time zone. Normally, GMT would be used by English Wikipedia, but as some users seem to have interpreted it as local time, maybe GMT-12 would be more suitable. I'd imagine that it wouldn't affect a lot of files. --Stefan2 (talk) 08:16, 12 September 2026 (UTC)