event

Event

Go to Comic

Title text: none

Explanation

This is not a comic, but a webpage on xkcd.com There are many other similar xkcd webpages, some of which are explained here. Explain xkcd is trying to decide how they should be treated. You are welcome to help us decide how we should categorise, call, or present these kinds of explanations. Kindly leave a comment here. This page should not be categorized until we decide how to explain these non-comics (see discussion above).

This is one of 52 incomplete explanations: This page was created by me, Caliban (again). Don't remove this notice too soon. If you can fix this issue, edit the page!

The purpose of this page is unclear. Though the image doesn't render on web browsers, it is visible when viewed locally. It appears to be a corrupted JPG.

Judging by the file name "newest.jpg", and the URL "event", this file may have been used for an (April Fools?) event, but after some edits was corrupted beyond recovery.

  Add comment        Create topic (use sparingly)       Refresh 

Discussion

What does this mean? Caliban (talk) 21:41, 16 August 2025 (UTC)

It means the denizens of this wiki try to document everything that Randall puts on the website, even if it's apparently a mistake and/or a corrupted file. 70.29.243.228 17:08, 18 August 2025 (UTC)

Why does this page have the refresh every 60 seconds html attribute? Preloading (talk) 20:43, 25 August 2025 (UTC)

After loading the image into a hex editor, I found that it is not an image, but a UTF-16LE with BOM file. The data look like this:

UTF-16LE with BOM data. There are multiple new lines trailing in the original data. The content may vary.

StatusCode        : 200
StatusDescription : OK
Content           : {255, 216, 255, 224...}
RawContent        : HTTP/1.1 200 OK
                    Connection: keep-alive
                    Age: 22
                    X-Served-By: cache-nrt-rjtt7900070-NRT
                    X-Cache: HIT
                    X-Cache-Hits: 1
                    X-Timer: S1756704587.574873,VS0,VE1
                    Accept-Ranges: bytes
                    Content-Length: 1359...
Headers           : {[Connection, keep-alive], [Age, 22], [X-Served-By, cache-n
                    rt-rjtt7900070-NRT], [X-Cache, HIT]...}
RawContentLength  : 1359

The Content field does indicate a valid JPEG image. So maybe this is a misconfigured CDN edge? Dousha99 (talk) 06:13, 1 September 2025 (UTC)

I'm sorry but what the hell are you talking about? > UTF-16LE with BOM file, for starters, the JPG does not contain BOM data (doesn't start with any of the BOM markings), and the JPG does not contain any coherent UTF-16LE text. What I assume you did was just cURL the request, and got back all the header data, and the raw http response that HTTP sends along. You can even see in the Content field the decimal array of the JPG. The actual data is a JPEG, not text. I also assume you ran a command to identify what type of file you got back from your cURL output (or whatever you used to make that request), which is why you said it was "UTF-16LE". Preloading (talk) 16:21, 13 September 2025 (UTC)

My apologies, I must have mistaken the header output for actual file content (since I have encountered similar issues so I assumed it was the same issue I've seen -- you cannot trust what URL have told you but I digress.). The actual newest.jpg is missing the EOI tag and is too short for an image of this dimension. There is no EXIF information. However, the dimensions itself are quite intriguing as they are both multiples of 8, which is the block size used by JPEG format. Dousha99 (talk) 14:09, 22 September 2025 (UTC)
        Add comment