Creating Data URLs is actually just a simple matter of base-64 encoding and prefixing the image – and for server-side or build-time usage, easy tools abound to do this.

But on the browser-side, creating a Data URL from a binary image is a bit fiddly: normally involving painting an already-loaded image onto a <canvas> element, and then calling toDataURL on it. What’s more, that technique doesn’t work when the image originally came from another domain (thanks to this).

If you’re creating applications that cache images offline in localStorage, you need to get this base-64 serialization. If these images come from another server, tinySrc offers a technique that will work.

It’s most likely that this feature will be used in a JSONP context – where you are passed the encoded form in a local callback function. You’re recommended to read the documentation – which includes a full sample doing just that.

Have fun and let me know if this API works out for you. Thanks!

tinySrc has been going from strength to strength over the last 18 months. I think its underlying growth is a reflection of the huge interest in developing for the mobile medium. Mobile web and app developers quickly realize they need to make sure that their graphical experience is correctly formatted for a wide range of screen-sizes and form factors.

There are no intentions to change the API and the way in which the tinySrc runs, so you can continue to use it with confidence.

I think you’ll see lots of new cool features coming in the future though, so stay tuned!

Previously, if the DeviceAtlas database did not know the screen-size of the browser requesting the image, it would default the value to 120 pixels.

This very rarely happens for mobile devices, but is a common occurrence for desktop browsers (where physical screen or window size can never be statically and meaningfully keyed off user-agent).

As a result, any tinySrc images for which you had not specified a dimension would appear constrained to 120px on desktop browsers. This looks strange of course, and makes it difficult for you to re-use markup and images across different broad device types.

Starting today, this defaulting has been refined. If the screen size is not known, we try further to identify whether the device is a mobile device or a desktop device. In the former case, we continue to default to 120px, but in the latter, we crank the default size up to 980px (which is the default iPhone viewport size, as it happens).

Since DeviceAtlas is extremely reliable about distinguishing mobile from non-mobile devices (even when the screen size is not known), this vastly improves the default experience, particularly for desktop browsers.

In summary, you should not need to make any changes to your code, and the API has not altered. The experience your mobile users receive will not have changed, and the experience your desktop users receive should have improved. And this only affects adaptive sizing: if you use explicit dimensions in your tinySrc usage, then the service’s behavior will not have changed at all.

Have fun and let us know if you have any questions.

• Support for non-Latin characters in URLs
  This was causing issues for Internationalized Domain Names and file names containing Chinese characters, for example.
• Auto-correction of corrupted URL scheme
  A small portion of requests arriving at our server were for http:/ instead of http://. These could have been markup errors, or more likely a correction to the URL that some mobile browsers were making, thinking that // was in error. We now re-insert the second / if it’s required to make the URL sensible.
• HTTP error proxying
  If your original image returns an error code (such as an HTTP 404 or 500 error), we relay that onto the user’s device. (Previously we returned a blank response with a 200 status code)
• Increased error verbosity
  Occasionally tinySrc encounters corrupt or extremely large images and can’t resize them. When the resizing engine fails, we provide a stack dump. Users never see this, because it’s not valid image data – but it allows you to debug what might have gone wrong with your image, and escalate it to us if necessary.

The good news is that none of this requires any changes to your code – the API has not changed at all.

tinySrc has picked up some great press recently, and we’re now more popular than ever! I hope you continue to find this service useful and let us know if you have any feedback.

Thanks for your support. Enjoy!

We’re very exciting to announce that we’ve partnered with the DeviceAtlas team over at dotMobi to bring you a great new capability for tinySrc.

We call it ‘adaptive sizing’.

There are thousands of different types of mobile handsets, and they all have different screen sizes. With tinySrc’s adaptive sizing, that’s now just one thing less to worry about when you’re developing a mobile web site. Take a look:

<img
 src='http://i.tinysrc.mobi/http://mysite.com/myimage.png'
 alt='My image, perfectly sized to the device screen'
/>

By default, tinySrc will now use the screen width and height values of the visiting phone to constrain your images. So you can be sure there won’t be any unpleasant scrollbars where there shouldn’t be.

You can also indicate that you want your images to take up specific portions of a mobile screen. Use the tinySrc API to deduct pixels from the screen size (perhaps to leave a deliberate border), or scale images to a given percentage of the screen (perhaps to create a well-aligned tiling effect).

<img
 src='http://i.tinysrc.mobi/x50/x50/http://mysite.com/myimage.png'
 alt='My image, in a quadrant of the screen'
/>

Pretty easy, huh?

All the details of the adaptive sizing feature are in a new section of the documentation, and we’d love to hear your feedback.

We’ve already had some amazing interest in the service as a whole – so we felt it deserved a lick of paint.

This blog will be the main way that we stay in touch with our users and listen to your needs and feedback. Please feel very comfortable using the blog to let us know how, when, and where you are using the service!

Many thanks for your support so far!