IMGSHARE allows authenticated users to upload image files to the server. Uploads are regular HTTP POST requests, authentication for scripts is done via a token passed as a POST argument along with the file. For web browsers using the regular web form, authentication involves logging in, receiving a cookie and then using it to do management actions, which is how most websites work.
Tokens are created by users on the web interface so scripts don't need fixed username or password auth data. A user can create as many tokens as they want. Tokens can have an expire time or last forever, the user can set how long tokens last. When tokens expire they immediately get deleted and stop showing up on the token list. Tokens can be deleted at any time via the web interface.
Note that scripts are only authorized to upload or delete images. In the future it might be possible to list one's own images but that feature isn't available yet. The web interface does have a list of uploaded images though.
Images, after being uploaded to the server, are verified for size and MIME type, and immediately uploaded to the third-party cloud server. An asynchronous script then creates the resized versions of the file and makes them available within a minute. This reduces instantaneous CPU load and reduces operating costs. Users never access the actual cloud storage server for uploads or downloads. Uploads first reach the web server and are later uploaded to the storage server, downloads are however routed immediately to the cloud storage server using a reverse proxy function. Downloads are not pre-buffered nor undergo a two-step download-and-serve process, they are passed through to the client in real time for reduced latency.
Only JPEG, BMP, PNG and WEBP files are supported. File extension is ignored for verification purposes but it may be stripped and replaced with the correct one if it's very wrong. The server will verify the MIME type by itself and expects to be able to identify one of the following types:
Broken files may be able to survive verification and the native (unaltered) file may be uploaded, but if the resizing tool (which actually opens and manipulates the image) fails its job, it may cause the image to be considered broken and the server will delete it.
Smaller files are allowed to last longer as they cost less on the server. It is encouraged that users make attempts to compress the images better before uploading, by using better encoding software or codecs where possible.
Users, depending on the uploaded file size, may be able to make files ephemeral or permanent. Ephemeral files can last any time from 1 hour to 365 days. Permanent files will not be automatically deleted by the system. In any case, the user is always able to delete a file manually and said deletion will take place immediately.
After upload, the server will try to convert files to so-called XGA, VGA and QVGA resolutions. Thumbnails will be generated as well but they will not be publicly accessible, they will be only for lists authorized users can see, entirely for convenience.
Those reduced images will be served from alternative locations so users could, in principle, alter the URI to access the smaller image files directly should they need to do that.
The original image files will always be accessible and will not be re-encoded in any way, they will be served verbatim how they were uploaded. This allows users to preserve quality as needed. URLs for the original files and all the resized versions are provided after upload.
All reduced files are encoded as JPEG to balance compatibility and file size. If a file has an aspect ratio different from these file sizes, aspect ratio will be preserved and the file will be resized so neither dimension exceeds its own limit.
WARNING: resizing files will not preserve EXIF tags, and sometimes such tags are required for image viewers to rotate an image that's encoded in one way but taken in another way. This is very common for smartphone photos, since the sensor only takes horizontal images and orientation is merely a tag on the file. This will cause images reliant on such tags to end up with the wrong orientation. Rotating the image is a feature that will be implemented later.
By default, endpoints will return JSON-formatted data to the client to deliver information like URLs, file lists and the like. The output format can be changed by requesting one output format as a POST or GET argument depending on the call. Supported output formats are JSON (default) and plaintext newline-separated key-value (Key=Value) pairs. XML may be supported in the future as well.
WARNING: Do not parse output that has an HTTP status code other than 200, as it may not be formatted as one expects. Instead, only interpret and use the status code itself. For example, error 429, which may be received as part of rate-limiting efforts, may not be controlled by the server scripts and instead will be returned directly by Nginx, which returns a human-readable HTML page by default instead.
The image upload endpoints are on the designated directory /api/v1/. For example, https://imgshare.danielthefox.com/api/v1/img_upload.php.
Images themselves are all stored in directories under /img/. Each account is assigned a subdirectory the name of the account name. This implies that account names are semi-permanent in the sense uploaded images under an account name will always have said account name forever. If there's an account called "kitten", all files uploaded by that account will end up under the /img/kitten/ directory.
The original or native version of a given image file is stored directly on said account directory. All files are prefixed with the date in YYYYMMDD format and an underscore symbol, regardless of the original or chosen filename on upload. For example, uploading a file called "fountain.jpg" and trying to preserve its original filename leads to a file called 20260214_fountain.jpg. With all and directories, the URI contains the string /img/kitten/20260214_fountain.jpg. This date is UTC.
The reduced files sit under subdirectories under the main account directory. Every file has three reduced versions as explained before: XGA, VGA and QVGA. Every file has all of these versions even if resizing or re-encoding is not required. They sit under the xga/, vga/ and qvga/, respectively. The actual filename under the directories is exactly the same as the native version of the file, except the extension will be stripped and replaced with .jpg, as the reduced versions are always JPEG files. For example, the XGA version of the example file above becomes /img/kitten/xga/20260214_fountain.jpg.
If, for example, the user "kitten" uploaded next day a file called "molly.png" and tried to preserve the original filename, the native version would end up being /img/kitten/20260215_molly.png. The VGA version of that file would sit on /img/kitten/vga/20260215_molly.jpg. Despite the fact the original file was a PNG file, the VGA version would be a JPEG file instead. The same would happen to the other reduced image file versions.
On the other hand, if a user called "reynard" uploaded a file called "fox.jpg", the file would end up on /img/reynard/20260215_fox.jpg instead. This ensures that people who regularly spot these links know who uploads those images.
As such, full links would wind up looking like the following examples:
Image files usually have names before they get uploaded. By default those filenames are not preserved on upload and they are replaced with randomly generated ones instead. They still get prefixed with the upload date though. However, if the user chooses to preserve the filename, the server will do its best to preserve it. If the extension is wrong, it may still be fixed, and regardless, the upload date will be prepended anyway.
As of now, the current API version is v1. There's no other version. This version was drafted in February 21, 2026. This API is intended for scripts, people who don't intend to use them don't need to read this section.
The API endpoints are all on the /api/v1/ directory.
GET-as-POST and POST-as-GET are not guaranteed to work, they may work or they may not work, and when it works, it may stop working without a warning.
Users must create an API token via the web interface. The API token looks roughly like this: "a9b8c7d6e5f4" or something like this, and is randomly generated while being created. This token may or not expire and can be removed at any time by the user. Users can create as many tokens as they want. Scripts don't require usernames or passwords to work, only the user's own token.
WARNING: Tokens must stay secret or else attackers can upload images without your consent.
All API calls that require a token must introduce it as a GET or POST argument (depending on the call), the argument name is always token. The presence of an auth token in a GET request as a GET parameter may trigger REST people.
--> POST /api/v1/img_upload.php
Uploads an image file to the server and returns a series of filenames.
The upload request is a POST using multipart/form-data encoding. Arguments are sent as POST parameters, the file is sent as one such parameter.
HTTP Status code: 200 OK
NOTE: do not parse the response body if the HTTP status code is other than 200. Only use the status code itself to understand what went wrong.
NOTE: filenames longer than 40 characters excluding the extension may be truncated. Some characters may be automatically converted to underscores. Unsupported values may be silently converted to their defaults instead.
--> POST /api/v1/img_delete.php
Deletes an image file from the server and returns confirmation if deletion succeeded.
The delete request uses the POST method. Arguments are sent as POST parameters.
NOTE: do not parse the body of this request, it does not return anything that's machine-readable.
--> GET /api/v1/universe_delete.php
Joke function designed to jolt readers and script writers awake like how a pothole jolts truckers up. It is expected to return error 403 if called correctly.
This request uses the GET method. Arguments are sent as GET parameters. This will trigger REST people too.
NOTE: do not parse the body of this request, it does not return anything that's machine-readable. If you are deleting the same universe the machine is in, the function should not have time to return success.
WARNING: This function may be disruptive, ensure that you have a backup of your image files beforehand.
--> POST /api/v1/img_gather.php
Loads an image into the server from an existing image link. This follows the same requirements as uploaded images and the end result is indistinguishable once the operation is done. For example, only JPEG, PNG, BMP and WEBP formats are supported, and the file limit is 32 MiB.
NOTE: This is already covered by the Terms of Service, but do not redistribute images you do not have permission for. This action leaves logs on external servers that include your username and this service's contact address on the user agent.
WARNING: The file will be fetched up to 32 MiB or when it finishes downloading, whichever happens first. If it's not done by 32 MiB, the server will abort and return an error. Errors will be passed as human-readable debug text to the user in the return body, but they are not guaranteed to be machine-readable. Any errors will be cached to avoid hammering an external server. Flaky servers can behave unpredictably as result. Secure websites with certificate errors will not be fetched and will return an error. Fetching from some restricted IP addresses, like localhost and local IP addresses, leads to errors as well.
The gathering request is a POST. Arguments are sent as POST parameters.
HTTP Status code: 200 OK
NOTE: do not parse the response body if the HTTP status code is other than 200. Only use the status code itself to understand what went wrong. The response body may be meaningful to humans instead.
NOTE: filenames longer than 40 characters excluding the extension may be truncated. Some characters may be automatically converted to underscores. Unsupported values may be silently converted to their defaults instead.